Closed
Bug 1326845
Opened 8 years ago
Closed 8 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•8 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•8 years ago
|
||
This bug isn't existent on beta (FF50), sounds a regression during the period.
Keywords: regression,
regressionwindow-wanted
Comment 4•8 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•8 years ago
|
||
Its possible this is a regression from bug 1303167.
Comment 6•8 years ago
|
||
[Tracking Requested - why for this release]:
User visible regression.
tracking-firefox52:
--- → ?
tracking-firefox53:
--- → ?
Assignee | ||
Comment 7•8 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•8 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•8 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•8 years ago
|
||
Verified on latest nightly. Feel free to re-open if you still encounter the issue.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Updated•8 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•