Last Comment Bug 421131 - Acid3 breaks backwards / forwards buttons
: Acid3 breaks backwards / forwards buttons
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
: Andrew Overholt [:overholt]
: 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:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

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 User image 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 User image -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 User image 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 User image Jerry Baker 2008-03-05 23:17:33 PST
Using the buttons are broken.
Comment 4 User image 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 and then going to 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 User image 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 User image -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 User image 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 User image -fullmetaljacket- 2008-03-12 19:52:58 PDT
nominating (to pickup appropriate blocking).
Comment 9 User image Boris Zbarsky [:bz] (still a bit busy) 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 User image 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 User image 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 User image Boris Zbarsky [:bz] (still a bit busy) 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 User image Mike Schroepfer 2008-03-19 14:20:24 PDT
Based on comment 9 we will not block on this.   
Comment 14 User image Damian Shaw [Quan] 2008-03-28 06:36:55 PDT
This is essentially a preview of Opera 10:

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

> 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 User image Boris Zbarsky [:bz] (still a bit busy) 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 User image 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 User image 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 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 User image 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 User image 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 User image 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 User image 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 User image Boris Zbarsky [:bz] (still a bit busy) 2008-04-04 06:43:32 PDT, 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 User image Matthias Versen [:Matti] 2008-04-06 16:27:30 PDT
*** Bug 427440 has been marked as a duplicate of this bug. ***
Comment 25 User image Gábor Stefanik 2008-11-08 08:53:49 PST
I think this is Core->Document Navigation.
Comment 26 User image Michał Gołębiowski [:mgol] 2009-06-20 06:01:10 PDT
And Linux (Ubuntu 8.04), too.
Comment 27 User image 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 User image 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 User image 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 User image 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 User image 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 User image Boris Zbarsky [:bz] (still a bit busy) 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 User image 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 User image Boris Zbarsky [:bz] (still a bit busy) 2010-08-27 12:10:45 PDT
Bug 293417 is all there ever was here, really.  It's just partially fixed now.
Comment 35 User image 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.