Enabling cookies causes callback links to incorrectly redirect in Firefox

> I've logged a bug: http://code.google.com/p/pier/issues/detail?id=132
>
> The text of the bug is:
>
>
> Steps to recreate the bug:
> 1) Download the recent build of Pier 2 -
> http://hudson.lukas-renggli.ch/job/Pier%202/ - this bug is not present
> in Pier with Seaside 2.8
> 2) In a workspace execute the following:
>
> PREventDistribution register.
> WAAdmin defaultDispatcher defaultHandler preferenceAt: #useCookies put: true.
> (PRPathLookup start: (PRKernel instances anyOne) root path: '/call')
> contents: 'In Firefox, try clicking on the counter
>
> +counter+'.
> (PRPathLookup start: (PRKernel instances anyOne) root path: '/call') addChild: (
> (PRComponent named: 'counter') componentClass: WACounter; yourself)
>
> 3) Within Firefox (I'm using 3.16.13) browse to
> http://localhost:8080/pier/call - you should be on the "Call for
> Contributions" page into which the above script embeds the standard
> Seaside counter component in the page.
> 4) Try clicking on the "++" or "--" links a couple of times and you'll
> find yourself taken to http://localhost:8080/pier/dates and rather
> than modifying the counter value.
>
> Here's my understanding of the bug:
>
> 1) Amongst other metadata Pier adds the following to the header: <link
> href="/pier/dates" rel="next">
> 2) In Firefox when cookies are enabled, the <link rel="next"> causes
> firefox to issue at least two requests for each page; the first
> request for the url specified, the second for the url specified in the
> href of the <link rel="next">. Note this second request is not visible
> in firebug (I added request logging to WAComancheRequestConverter). In
> Safari or Chrome, I haven't seen any additional requests and so the
> problem does not appear.
> 3) The second request confuses the callback hander
>
> Unfortunately my understanding of how the callback handler should work
> is limiting my ability to fix the bug. Any thoughts?
>

> I've uploaded an image which demonstration the issue:
> http://getitmade.com/static/Pier-2.zip
>
> Download and browse to http://localhost:8080/pier/call
> Click on the "++" or "--" links of the WACounter instance twice in Firefox.
> Notice that only in Firefox the second click of the callback take you
> to http://localhost:8080/pier/dates rather than incrementing the
> counter.
>
> On 26 February 2011 15:50, Nick Ager <[hidden email]> wrote:
>> I've logged a bug: http://code.google.com/p/pier/issues/detail?id=132
>>
>> The text of the bug is:
>>
>>
>> Steps to recreate the bug:
>> 1) Download the recent build of Pier 2 -
>> http://hudson.lukas-renggli.ch/job/Pier%202/ - this bug is not present
>> in Pier with Seaside 2.8
>> 2) In a workspace execute the following:
>>
>> PREventDistribution register.
>> WAAdmin defaultDispatcher defaultHandler preferenceAt: #useCookies put: true.
>> (PRPathLookup start: (PRKernel instances anyOne) root path: '/call')
>> contents: 'In Firefox, try clicking on the counter
>>
>> +counter+'.
>> (PRPathLookup start: (PRKernel instances anyOne) root path: '/call') addChild: (
>> (PRComponent named: 'counter') componentClass: WACounter; yourself)
>>
>> 3) Within Firefox (I'm using 3.16.13) browse to
>> http://localhost:8080/pier/call - you should be on the "Call for
>> Contributions" page into which the above script embeds the standard
>> Seaside counter component in the page.
>> 4) Try clicking on the "++" or "--" links a couple of times and you'll
>> find yourself taken to http://localhost:8080/pier/dates and rather
>> than modifying the counter value.
>>
>> Here's my understanding of the bug:
>>
>> 1) Amongst other metadata Pier adds the following to the header: <link
>> href="/pier/dates" rel="next">
>> 2) In Firefox when cookies are enabled, the <link rel="next"> causes
>> firefox to issue at least two requests for each page; the first
>> request for the url specified, the second for the url specified in the
>> href of the <link rel="next">. Note this second request is not visible
>> in firebug (I added request logging to WAComancheRequestConverter). In
>> Safari or Chrome, I haven't seen any additional requests and so the
>> problem does not appear.
>> 3) The second request confuses the callback hander
>>
>> Unfortunately my understanding of how the callback handler should work
>> is limiting my ability to fix the bug. Any thoughts?
>>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>

> Thanks for preparing the image and sorry for not looking into it
> earlier. I will try to look into this problem tonight.
>
> Lukas
>
> On 27 February 2011 14:16, Nick Ager <[hidden email]> wrote:
>> I've uploaded an image which demonstration the issue:
>> http://getitmade.com/static/Pier-2.zip
>>
>> Download and browse to http://localhost:8080/pier/call
>> Click on the "++" or "--" links of the WACounter instance twice in Firefox.
>> Notice that only in Firefox the second click of the callback take you
>> to http://localhost:8080/pier/dates rather than incrementing the
>> counter.
>>
>> On 26 February 2011 15:50, Nick Ager <[hidden email]> wrote:
>>> I've logged a bug: http://code.google.com/p/pier/issues/detail?id=132
>>>
>>> The text of the bug is:
>>>
>>>
>>> Steps to recreate the bug:
>>> 1) Download the recent build of Pier 2 -
>>> http://hudson.lukas-renggli.ch/job/Pier%202/ - this bug is not present
>>> in Pier with Seaside 2.8
>>> 2) In a workspace execute the following:
>>>
>>> PREventDistribution register.
>>> WAAdmin defaultDispatcher defaultHandler preferenceAt: #useCookies put: true.
>>> (PRPathLookup start: (PRKernel instances anyOne) root path: '/call')
>>> contents: 'In Firefox, try clicking on the counter
>>>
>>> +counter+'.
>>> (PRPathLookup start: (PRKernel instances anyOne) root path: '/call') addChild: (
>>> (PRComponent named: 'counter') componentClass: WACounter; yourself)
>>>
>>> 3) Within Firefox (I'm using 3.16.13) browse to
>>> http://localhost:8080/pier/call - you should be on the "Call for
>>> Contributions" page into which the above script embeds the standard
>>> Seaside counter component in the page.
>>> 4) Try clicking on the "++" or "--" links a couple of times and you'll
>>> find yourself taken to http://localhost:8080/pier/dates and rather
>>> than modifying the counter value.
>>>
>>> Here's my understanding of the bug:
>>>
>>> 1) Amongst other metadata Pier adds the following to the header: <link
>>> href="/pier/dates" rel="next">
>>> 2) In Firefox when cookies are enabled, the <link rel="next"> causes
>>> firefox to issue at least two requests for each page; the first
>>> request for the url specified, the second for the url specified in the
>>> href of the <link rel="next">. Note this second request is not visible
>>> in firebug (I added request logging to WAComancheRequestConverter). In
>>> Safari or Chrome, I haven't seen any additional requests and so the
>>> problem does not appear.
>>> 3) The second request confuses the callback hander
>>>
>>> Unfortunately my understanding of how the callback handler should work
>>> is limiting my ability to fix the bug. Any thoughts?
>>>
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>>
>
>
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>

> That was a tricky one:
>
> Unfortunately the Mozilla engine does prefetching of some "random"
> links on websites
> (https://developer.mozilla.org/en/Link_prefetching_FAQ). This
> aggressive prefixing is a highly controversial topic even in the
> FireFox community itself, because of all kinds of issues.
>
> Now obviously this prefetching is generally something we don't want to
> happen with Seaside applications as callbacks could unwillingly be
> triggered. I changed the Seaside code to deny all prefetch requests in
> WAApplication. This should solve the problem:
>
>  Name: Seaside-Core-lr.711
>  Author: lr
>  Time: 7 March 2011, 6:52:15 pm
>  UUID: 57d701cc-b90b-458d-9f7a-cf9a493a9997
>  Ancestors: Seaside-Core-dkh.710
>
>  - added a tester for prefetch requests
>
>  Name: Seaside-Session-lr.135
>  Author: lr
>  Time: 7 March 2011, 6:53:50 pm
>  UUID: 07b0af88-64b7-4bcb-8778-d14e448dddd9
>  Ancestors: Seaside-Session-pmm.134
>
> Lukas
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>

> This is, of course, part of the problem with using GET requests for
> callbacks... shame you can't specify POST in an href anchor... :)
>
> Julian
>
> On Mon, Mar 7, 2011 at 6:00 PM, Lukas Renggli <[hidden email]> wrote:
>> That was a tricky one:
>>
>> Unfortunately the Mozilla engine does prefetching of some "random"
>> links on websites
>> (https://developer.mozilla.org/en/Link_prefetching_FAQ). This
>> aggressive prefixing is a highly controversial topic even in the
>> FireFox community itself, because of all kinds of issues.
>>
>> Now obviously this prefetching is generally something we don't want to
>> happen with Seaside applications as callbacks could unwillingly be
>> triggered. I changed the Seaside code to deny all prefetch requests in
>> WAApplication. This should solve the problem:
>>
>>  Name: Seaside-Core-lr.711
>>  Author: lr
>>  Time: 7 March 2011, 6:52:15 pm
>>  UUID: 57d701cc-b90b-458d-9f7a-cf9a493a9997
>>  Ancestors: Seaside-Core-dkh.710
>>
>>  - added a tester for prefetch requests
>>
>>  Name: Seaside-Session-lr.135
>>  Author: lr
>>  Time: 7 March 2011, 6:53:50 pm
>>  UUID: 07b0af88-64b7-4bcb-8778-d14e448dddd9
>>  Ancestors: Seaside-Session-pmm.134
>>
>> Lukas
>>
>> --
>> Lukas Renggli
>> www.lukas-renggli.ch
>> _______________________________________________
>> seaside-dev mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>
>