Closed
Bug 1003100
Opened 10 years ago
Closed 9 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•10 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•9 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•9 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•9 years ago
|
||
We are getting this pretty frequently from our users too at Disqus.
Comment 5•9 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•9 years ago
|
Comment 6•9 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•9 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•9 years ago
|
Assignee: nobody → bugs
Flags: needinfo?(bugs)
Assignee | ||
Comment 8•9 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•9 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•9 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•9 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=93686ed30a12
Comment 13•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/4f4e54b55fc8
Status: NEW → RESOLVED
Closed: 9 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
•