Closed
Bug 1003100
Opened 11 years ago
Closed 10 years ago
pushState() in iframe fails when reloading with CTRL+F5
Categories
(Core :: DOM: Navigation, defect)
Core
DOM: Navigation
Tracking
()
RESOLVED
FIXED
mozilla44
Tracking | Status | |
---|---|---|
firefox44 | --- | fixed |
People
(Reporter: sigi, Assigned: smaug)
Details
(Keywords: DevAdvocacy, testcase)
Attachments
(3 files)
1.11 KB,
text/html
|
Details | |
4.81 KB,
patch
|
bzbarsky
:
review+
|
Details | Diff | Splinter Review |
4.80 KB,
patch
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 2014031500
Steps to reproduce:
1. Open console
2. Go to http://jsbin.com/vadoloda
3. See log message "iframe content"
4. Reload Page by pressing F5
5. No NS_ERROR_FAILURE occurs
6. Reload Page by pressing CTRL+F5
7. An NS_ERROR_FAILURE occurs
Actual results:
NS_ERROR_FAILURE:
window.history.pushState(null, null, "#foo")
Expected results:
No NS_ERROR_FAILURE should happen.
Comment 1•11 years ago
|
||
Reproduced on Windows 7 64bit and Mac OS X 10.9.2 using latest Nightly.
Status: UNCONFIRMED → NEW
Component: Untriaged → Document Navigation
Ever confirmed: true
Product: Firefox → Core
Version: 28 Branch → Trunk
Comment 2•10 years ago
|
||
Still valid and 100% reproducible in latest release of FireFox (v37.0.1 at time of this writing). Only appears to a occur with a hard refresh(`shift + f5` on Windows, `cmd + shift + r` on Mac), cannot reproduce with standard refresh(e.g. click refresh button in browser, `f5` on Windows, `cmd + r` on Mac) or on first time load of page.
Comment 3•10 years ago
|
||
It may be interseting to note that it still occurs with firefox nightly (41 at the time of this writing).
In my case, I have an application that answers to user action by
1. creating an iframe
2. calling window.pushState on the new iframe
It works perfectly unless I have used ctrl + f5 before. Then, when I use my button (even if I wait a long after the hard reload), I get an NS_ERROR_FAILURE
Comment 4•10 years ago
|
||
We are getting this pretty frequently from our users too at Disqus.
Comment 5•10 years ago
|
||
The problem is that we're failing at:
NS_ENSURE_TRUE(mOSHE) failed: file /docshell/base/nsDocShell.cpp, line 11483
https://mxr.mozilla.org/mozilla-central/source/docshell/base/nsDocShell.cpp?rev=982d9a863989#11483
smaug, any chance you or someone else could take a quick look at this to at least see if there is a simple fix?
Flags: needinfo?(bugs)
Updated•10 years ago
|
Comment 6•10 years ago
|
||
Comment on attachment 8663788 [details]
Testcase to run from a file
For some reason this testcase doesn't work from BMO but works from a file URI. In case it isn't clear, this isn't specific to @srcdoc usage, I just used that to make the testcase self-contained.
Attachment #8663788 -
Attachment description: Testcase → Testcase to run from a file
Assignee | ||
Comment 7•10 years ago
|
||
That testcase with srcdoc doesn't seem to work, but let me try to find some time for this, perhaps next week.
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → bugs
Flags: needinfo?(bugs)
Assignee | ||
Comment 8•10 years ago
|
||
This is super fragile, but the issue is that we propagate loadtype to subframes, even though those are in shift-reload case newly created iframes and should get an mLSHE (which is then later moved to mOSHE).
https://treeherder.mozilla.org/#/jobs?repo=try&revision=85228661f4a3
The issue with srcdoc is https://bugzilla.mozilla.org/show_bug.cgi?id=1215298
Attachment #8674502 -
Flags: review?(bzbarsky)
![]() |
||
Comment 9•10 years ago
|
||
Comment on attachment 8674502 [details] [diff] [review]
v1
r=let's-pretend-I'd-have-noticed-if-there-were-something-wrong-here.
Attachment #8674502 -
Flags: review?(bzbarsky) → review+
Assignee | ||
Comment 10•10 years ago
|
||
And based on try the assertion is too strong. We don't create a new entry anyway if we already have
mLSHE, so removing !mLSHE from the assertion.
Assignee | ||
Comment 11•10 years ago
|
||
Comment 12•10 years ago
|
||
Comment 13•10 years ago
|
||
Status: NEW → RESOLVED
Closed: 10 years ago
status-firefox44:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
You need to log in
before you can comment on or make changes to this bug.
Description
•