26 Feb
2011
26 Feb
'11
4:50 p.m.
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?
27 Feb
27 Feb
2:16 p.m.
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> 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?
7 Mar
7 Mar
6:29 p.m.
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> 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> wrote:
--
Lukas Renggli
www.lukas-renggli.ch
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
7 p.m.
No problem - The simplest illustration of the problem is probably to
execute the following on a Pier 2 image (no need to download the image
I've prepared):
createSimplestPierIllustratingCallbackProblemInFirefox
| app rootPage |
rootPage := (PRPage named: 'rootPage') contents: '*counter*
*shouldntgohere*'; yourself.
rootPage localEnvironment: ((PRComponent named: 'contents')
componentClass: PRContentsWidget; yourself).
rootPage addChild: ((PRComponent named: 'counter') componentClass:
WACounter; yourself).
rootPage addChild: ((PRPage named: 'shouldntgohere') contents:
'shouldn''t be here'; yourself).
PRKernel reset.
app := PRPierFrame registerAsApplication: 'pier' kernel: (PRKernel
named: 'testKernel' root: rootPage).
app preferenceAt: #useCookies put: true.
On 7 March 2011 17:29, Lukas Renggli <renggli(a)gmail.com> wrote:
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> 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> wrote:
--
Lukas Renggli
www.lukas-renggli.ch
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
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
7 p.m.
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
9 Mar
9 Mar
9:15 a.m.
New subject: [Seaside-dev] Re: Enabling cookies causes callback links to incorrectly redirect in Firefox
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 <renggli(a)gmail.com> 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
seaside-dev(a)lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
5:28 p.m.
Somehow similar (and not adressed by my fix) is that Chrome is doing
"random" GET requests when you type an URL to provide auto-completion.
I assume that this is less likely to hit a Seaside callback, but we
should still pay attention.
Lukas
On Wednesday, 9 March 2011, Julian Fitzell <jfitzell(a)gmail.com> wrote:
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 <renggli(a)gmail.com> wrote:
--
Lukas Renggli
www.lukas-renggli.ch
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
5045
days inactive
5056
days old
6 comments
3 participants
participants (3)
-
Julian Fitzell -
Lukas Renggli -
Nick Ager