Closed
Bug 1326845
Opened 6 years ago
Closed 6 years ago
Reloading a page with iframe mess up the tab history
Categories
(Core :: DOM: Navigation, defect)
Core
DOM: Navigation
Tracking
()
RESOLVED
DUPLICATE
of bug 1326251
People
(Reporter: arni2033, Assigned: freesamael)
Details
Attachments
(1 file)
342 bytes,
text/html
|
Details |
>>> My Info: Win7_64, Nightly 49, 32bit, ID 20160526082509 STR_1: 1. Open "testcase 1" in a new tab 2. Wait until the title of the tab changes to "1. Press F5" 3. Press F5 4. Right-click Back button in urlbar, then click item "0. Wait" in tab history AR: No visible action. Error [1] in console. ER: Either don't show me that history item, or do something sensible if it's shown STR_2: 1. Copy url of "testcase 1" to clipboard 2. Open http://example.org 3. Right-click uribar, click "Paste and go" 4. Wait until the title of the tab changes to "1. Press F5" 5. Press F5, wait 4 seconds 6. Right-click Back button in urlbar, then click the lower item "0. Wait" in tab history (bonus) - there's already a bug, but if you continue, there'll be more 7. Click Forward button in urlbar or press Alt+Right 8. Click Forward button in urlbar or press Alt+Right 9. Right-click Back button in urlbar, then click on the 1st item in tab history ("1. Press F5") AR: Step 6 - browser switched to the url from Step 2 (http://example.org) Step 8 - No visible action. Error [2] in console Step 9 - No visible action. Error [1] in console ER: Either don't show me inactive forward button/history items, or do something sensible if they're shown Behavior of STR_2 Step 6 is not "sensible", because it opens wrong item, not the one I clicked [1] chrome://global/content/browser-child.js:304 NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIWebNavigation.gotoIndex] [2] chrome://global/content/browser-child.js:299 NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIWebNavigation.goForward]
Component: Untriaged → Document Navigation
Product: Firefox → Core
Comment 1•6 years ago
|
||
Hi arni2033, thanks for reporting this issue, but it seems "testcase 1" you mentioned in comment 0 is missing. Could you please attach it?
Flags: needinfo?(arni2033)
Comment 3•6 years ago
|
||
This bug isn't existent on beta (FF50), sounds a regression during the period.
Keywords: regression,
regressionwindow-wanted
Comment 4•6 years ago
|
||
(In reply to Hsin-Yi Tsai [:hsinyi] from comment #3) > This bug isn't existent on beta (FF50), sounds a regression during the ^^^^^^ typo, should be beta FF51 > period.
Comment 5•6 years ago
|
||
Its possible this is a regression from bug 1303167.
Comment 6•6 years ago
|
||
[Tracking Requested - why for this release]: User visible regression.
tracking-firefox52:
--- → ?
tracking-firefox53:
--- → ?
Assignee | ||
Comment 7•6 years ago
|
||
I tried mozgression but couldn't find a good build even at 2011-ish builds. The symptom doesn't exist on latest aurora / beta so it's more likely to be a nightly-only bug than a regression. It's making testing of bug 1326251 being difficult as I couldn't get correct history.length. I'll take the task to investigate it.
Assignee | ||
Comment 8•6 years ago
|
||
I was wrong about the dependency. I'm still trying to figure out what happened but it's not related to the testing issue I encountered in bug 1326251. I was confused.
No longer blocks: 1326251
Assignee | ||
Comment 10•6 years ago
|
||
We concluded that frame history entries should be removed on reloading in bug 1326251, so this bug should also be fixed by that change. I'll revalidate once the patch lands.
Assignee | ||
Comment 11•6 years ago
|
||
Verified on latest nightly. Feel free to re-open if you still encounter the issue.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•