Last Comment Bug 421131 - Acid3 breaks backwards / forwards buttons
: Acid3 breaks backwards / forwards buttons
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Document Navigation (show other bugs)
: Trunk
: All All
: -- major with 13 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://www.webstandards.org/action/acid3
: 427440 509920 (view as bug list)
Depends on: 462076
Blocks: backtraps acid3
  Show dependency treegraph
 
Reported: 2008-03-05 11:16 PST by Damian Shaw [Quan]
Modified: 2010-09-30 01:58 PDT (History)
39 users (show)
mtschrep: blocking1.9-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
final+


Attachments
somewhat reduced testcase (1.74 KB, text/html)
2008-04-04 05:30 PDT, Aiko
no flags Details
minimised testcase (350 bytes, text/html)
2008-04-04 06:12 PDT, Aiko
no flags Details

Description Damian Shaw [Quan] 2008-03-05 11:16:01 PST
Running the current Acid3 test on:

Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9b5pre) Gecko/2008030506 Minefield/3.0b5pre ID:2008030506

I can no longer press back or forwards buttons and get anywhere.
Comment 1 -fullmetaljacket- 2008-03-05 17:18:16 PST
WFM with

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008030516 Minefield/3.0b5pre ID:2008030516
Comment 2 Damian Shaw [Quan] 2008-03-05 19:21:24 PST
I restarted computer and tested in Firefox Safe Mode, still broken, but yours is a slightly newer build, so I'll test again tomorrow on the new nightly build.
Comment 3 Jerry Baker 2008-03-05 23:17:33 PST
Using 2.0.0.12 the buttons are broken.
Comment 4 Landon Abney 2008-03-11 11:29:40 PDT
On the following build:
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b5pre) Gecko/2008031004 Minefield/3.0b5pre ID:2008031004

I see the following:
After going to www.google.com and then going to acid3.acidtests.org I see 4 entries for "The Acid3 Test" in the history for that page. The back and forward buttons  work properly when either Google or the first Acid3 entry are selected. If Any of the last 3 entries for Acid3 are selected the back and forward buttons are locked to their current position in the history for that tab.
Comment 5 Barrie North 2008-03-12 05:35:38 PDT
using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b5pre) Gecko/2008031109 Minefield/3.0b5pre ID:2008031109 i get something similar

if you load a site... say google, then go to the acid3 test page, then go to another site, pressing back will take you back to the acid 3 page, but pressing it again even repeatedly takes you no further, pressing forward will still take you to the site you visited after the acid3 test

plus the acid3 page shows up 4 times in the drop-down for me as well
Comment 6 -fullmetaljacket- 2008-03-12 19:29:44 PDT
i can now reproduce this using str from comment #5 on
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008031115 Minefield/3.0b5pre ID:2008031115

btw, windows only?
Comment 7 philippe (part-time) 2008-03-12 19:46:57 PDT
(In reply to comment #6)

Mac also (Minefield and Camino trunk).
And this should be Core, not sure which component though.
Comment 8 -fullmetaljacket- 2008-03-12 19:52:58 PDT
nominating (to pickup appropriate blocking).
Comment 9 Boris Zbarsky [:bz] (Out June 25-July 6) 2008-03-16 13:44:13 PDT
So what's the issue here?  The fact that some intermediate pages on the Acid3 test do the equivalent of:

 <body onload="setTimeout(0, function() { window.location = 'something' })">

That sort of page will "break" history no matter what.

If it's not a regression from Gecko 1.8 (doesn't sound like it is), and it's not clear what the right behavior is (which it's not, until someone produces a reduced testcase), this shouldn't block.

Once we have a reduced testcase there can at least be a discussion about what the correct behavior is, of course.  I suspect at that point this bug will be marked duplicate, though.

(I should also note that any non-regression session history bug that's not a security hole or crash issue is not a blocker and shouldn't have been for at least 5-6 months now.)
Comment 10 Damian Shaw [Quan] 2008-03-16 17:11:33 PDT
Hmm, well I tried coming up with a simplified test case, simply by copying and pasting the acid3 source code and trying it offline.

It semi-broke the back button (pressing back twice worked, where as on the actual acidtest I can press back as many times as I want and it doesn't work). So this bug make break down in to several bugs. I'll try and come up with simplified test cases, but I'm not really very knowledgeable with JavaScript, so other people feel free to do so.
Comment 11 Jerry Baker 2008-03-16 20:37:47 PDT
(In reply to comment #9)
> So what's the issue here?  The fact that some intermediate pages on the Acid3
> test do the equivalent of:
> 
>  <body onload="setTimeout(0, function() { window.location = 'something' })">

I suppose if one does not think Firefox should be able to navigate to pages visited prior to encountering such a JavaScript, then there is no problem. If you think the back button should go back after a JavaScript loads a page, then this is a problem.
Comment 12 Boris Zbarsky [:bz] (Out June 25-July 6) 2008-03-16 21:16:54 PDT
You can always navigate to pages before such a page using the history dropdown, of course.  And not running javascript on load from history (if loading from cache, not bfcache) would break a lot of pages.

But all that is academic until someone sorts out exactly what acid3 is doing.
Comment 13 Mike Schroepfer 2008-03-19 14:20:24 PDT
Based on comment 9 we will not block on this.   
Comment 14 Damian Shaw [Quan] 2008-03-28 06:36:55 PDT
This is essentially a preview of Opera 10: http://labs.opera.com/news/2008/03/28/

In this you have to press the back button 5 times to go back, so not completely breaking the back button.
Comment 15 Damian Shaw [Quan] 2008-04-03 19:23:51 PDT
Just e-mailed Hixie about this:

Hixie:
> As far as I know it shouldn't affect the back button at all. I guess there
> might be some interaction with iframes, but since they're hidden, that's
> probably a bug.
Comment 16 Boris Zbarsky [:bz] (Out June 25-July 6) 2008-04-03 20:26:33 PDT
Iframes being hidden has nothing to do with how they affect session history.

What this bug still needs is someone stripping out all the parts of acid3 that are not relevant to causing this problem.  I might be able to do that in June, but if someone gets to it before then, that would be greatly appreciated.
Comment 17 Damian Shaw [Quan] 2008-04-04 03:51:46 PDT
Well the question was raised here on what "expected behavior" was and whether the back button should even work at all. I'll try my best to break down the test and find the problem, but I don't have a lot of experience deciphering JavaScript, so might take me a while just to work out how to download the full test.
Comment 18 Aiko 2008-04-04 05:30:53 PDT
Created attachment 313596 [details]
somewhat reduced testcase

Please note that the back button stays functional while the iframes are still visible. The back button breaks as soon as this line is executed:

    kungFuDeathGrip.parentNode.removeChild(kungFuDeathGrip);

kungFuDeathGrip is a P element with 4 iframe children, its parent is BODY. With less than 4 iframes the back button doesn't break either.
Comment 19 Damian Shaw [Quan] 2008-04-04 05:41:52 PDT
Yup, can confirm this. Been playing around with the Acid3 test today, managed to get it mostly working offline and able to duplicate this bug.

Every time you remove only 1 test with the kungFuDeathGrip in it, the back button works again, e.g test 65.
Comment 20 Aiko 2008-04-04 05:56:42 PDT
Doh, of course you need at least 4 iframes because test 71 uses childNodes[3]. Replace that with childNodes[0] and 1 iframe is sufficient.
Comment 21 Aiko 2008-04-04 06:12:14 PDT
Created attachment 313599 [details]
minimised testcase

This is based on the testcase from bug 148794, I simply added one line that removes the iframe from the document.
Comment 22 Damian Shaw [Quan] 2008-04-04 06:19:12 PDT
huh, is it bug 148794 then that causes the Acid3 test to appear multiple times in back button drop down menu then? In which case should it be blocking the the Acid3 meta tracking bug?
Comment 23 Boris Zbarsky [:bz] (Out June 25-July 6) 2008-04-04 06:43:32 PDT
Seno.Aiko@live.com, thanks for minimizing this.

This isn't quite bug 148794.  That bug is about the entries being added (which I think is the right behavior). This bug has to do with things breaking when an iframe in which those navigations happened is removed from the document.  That looks more like bug 293417 to me, though that bug doesn't talk about explicit back button bustage.  So I'd be inclined to treat this as a separate bug, myself.

In any case, now that we know what's going on, we can try fixing it.  I agree this is definitely a Gecko bug.
Comment 24 Matthias Versen [:Matti] 2008-04-06 16:27:30 PDT
*** Bug 427440 has been marked as a duplicate of this bug. ***
Comment 25 Gábor Stefanik 2008-11-08 08:53:49 PST
I think this is Core->Document Navigation.
Comment 26 Michał Gołębiowski [:m_gol] 2009-06-20 06:01:10 PDT
@-fullmetaljacket-
And Linux (Ubuntu 8.04), too.
Comment 27 Ria Klaassen (not reading all bugmail) 2009-08-12 04:33:26 PDT
*** Bug 509920 has been marked as a duplicate of this bug. ***
Comment 28 Christopher Stone 2010-08-26 18:20:52 PDT
People are starting to use this bug to prevent users from using the back arrow button to leave a site. :(
Comment 29 Gábor Stefanik 2010-08-26 18:28:53 PDT
(In reply to comment #28)
> People are starting to use this bug to prevent users from using the back arrow
> button to leave a site. :(

Can you name a specific site that does this?
Comment 30 Brian Carpenter [:geeknik] 2010-08-26 20:45:45 PDT
WFM with the latest hourly build of Minefield. So I'm pretty sure that whatever sites are supposedly using this bug to keep people from leaving won't have much luck with Firefox 4 is released.
Comment 31 Damian Shaw [Quan] 2010-08-26 22:01:35 PDT
There does seem to have been a partial/fix at some point. The minimized test case no longer works and the Acid3 site requires you to only click back twice.
Comment 32 Boris Zbarsky [:bz] (Out June 25-July 6) 2010-08-26 22:45:36 PDT
The partial fix was bug 462076.  Olli, is it expected that you still get one new shentry here?
Comment 33 Gábor Stefanik 2010-08-27 11:44:00 PDT
Well, if now going back only requires multiple clicks, but doesn't completely break the back button, that's bug 293417. I believe this can be marked as FIXED then. Thoughts?
Comment 34 Boris Zbarsky [:bz] (Out June 25-July 6) 2010-08-27 12:10:45 PDT
Bug 293417 is all there ever was here, really.  It's just partially fixed now.
Comment 35 Frank Yan (:fryn) 2010-08-27 12:57:40 PDT
Marking fixed, since this particular issue was addressed in bug 462076.
See comment #33, comment #34, and bug 293417.

Note You need to log in before you can comment on or make changes to this bug.