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)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla44
Tracking Status
firefox44 --- fixed

People

(Reporter: sigi, Assigned: smaug)

Details

(Keywords: DevAdvocacy, testcase)

Attachments

(3 files)

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.
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
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.
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
We are getting this pretty frequently from our users too at Disqus.
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)
OS: Linux → All
Hardware: x86_64 → All
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
That testcase with srcdoc doesn't seem to work, but let me try to find some time for this, perhaps next week.
Assignee: nobody → bugs
Flags: needinfo?(bugs)
Attached patch v1Splinter Review
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 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+
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.
https://hg.mozilla.org/mozilla-central/rev/4f4e54b55fc8
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: