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?

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 <nick.ager(a)gmail.com&gt; 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 <nick.ager(a)gmail.com&gt; 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 seaside-dev(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev