Acid3 breaks backwards / forwards buttons

RESOLVED FIXED

Status

()

Core
Document Navigation
--
major
RESOLVED FIXED
10 years ago
7 years ago

People

(Reporter: Damian Shaw [Quan], Unassigned)

Tracking

Trunk
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 -

Firefox Tracking Flags

(blocking2.0 final+)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

350 bytes, text/html
Details
(Reporter)

Description

10 years ago
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.
(Reporter)

Updated

10 years ago
Severity: normal → major

Comment 1

10 years ago
WFM with

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

Comment 2

10 years ago
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

10 years ago
Using 2.0.0.12 the buttons are broken.

Updated

10 years ago
(Reporter)

Updated

10 years ago
Blocks: 410460

Comment 4

10 years ago
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

10 years ago
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

10 years ago
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

10 years ago
(In reply to comment #6)

Mac also (Minefield and Camino trunk).
And this should be Core, not sure which component though.
Component: General → General
OS: Windows Server 2003 → All
Product: Firefox → Core
QA Contact: general → general
Hardware: PC → All

Comment 8

10 years ago
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.)
(Reporter)

Comment 10

10 years ago
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

10 years ago
(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.

Comment 13

10 years ago
Based on comment 9 we will not block on this.   
Flags: blocking1.9? → blocking1.9-
(Reporter)

Comment 14

10 years ago
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.
(Reporter)

Comment 15

10 years ago
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.
(Reporter)

Comment 17

10 years ago
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

10 years ago
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.
(Reporter)

Comment 19

10 years ago
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

10 years ago
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

10 years ago
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.
Attachment #313596 - Attachment is obsolete: true
(Reporter)

Comment 22

10 years ago
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: 340021
Duplicate of this bug: 427440

Comment 25

9 years ago
I think this is Core->Document Navigation.
Component: General → Document Navigation
QA Contact: general → docshell
@-fullmetaljacket-
And Linux (Ubuntu 8.04), too.
Duplicate of this bug: 509920

Comment 28

7 years ago
People are starting to use this bug to prevent users from using the back arrow button to leave a site. :(
blocking2.0: --- → ?

Comment 29

7 years ago
(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.
(Reporter)

Comment 31

7 years ago
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

Comment 33

7 years ago
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.

Comment 35

7 years ago
Marking fixed, since this particular issue was addressed in bug 462076.
See comment #33, comment #34, and bug 293417.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED

Updated

7 years ago
blocking2.0: ? → final+
You need to log in before you can comment on or make changes to this bug.