Closed Bug 421131 Opened 16 years ago Closed 14 years ago

Acid3 breaks backwards / forwards buttons

Categories

(Core :: DOM: Navigation, defect)

Product:
Core
Component:
DOM: Navigation
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
blocking2.0 --- final+

People

(Reporter: zurtex, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

Attachments

(1 file, 1 obsolete file)

minimised testcase
350 bytes, text/html
Details 
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.
Severity: normal → major
WFM with

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008030516 Minefield/3.0b5pre ID:2008030516
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.
Using 2.0.0.12 the buttons are broken.
Blocks: acid3
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.
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
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?
(In reply to comment #6)

Mac also (Minefield and Camino trunk).
And this should be Core, not sure which component though.
OS: Windows Server 2003 → All
Product: Firefox → Core
QA Contact: general → general
Hardware: PC → All
nominating (to pickup appropriate blocking).
Flags: blocking1.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' })">

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.)
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.
(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.
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.
Based on comment 9 we will not block on this.
Flags: blocking1.9? → blocking1.9-
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.
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.
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.
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.
Attached file somewhat reduced testcase (obsolete) — 
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.
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.
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.
Attached file minimised testcase — 
This is based on the testcase from bug 148794, I simply added one line that removes the iframe from the document.
Attachment #313596 - Attachment is obsolete: true
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?
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.
Blocks: backtraps
I think this is Core->Document Navigation.
Component: General → Document Navigation
QA Contact: general → docshell
@-fullmetaljacket-
And Linux (Ubuntu 8.04), too.
People are starting to use this bug to prevent users from using the back arrow button to leave a site. :(
blocking2.0: --- → ?
(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?
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.
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.
The partial fix was bug 462076.  Olli, is it expected that you still get one new shentry here?
Depends on: 462076
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?
Bug 293417 is all there ever was here, really.  It's just partially fixed now.
Marking fixed, since this particular issue was addressed in bug 462076.
See comment #33, comment #34, and bug 293417.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
blocking2.0: ? → final+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: