The default bug view has changed. See this FAQ.

"Assertion failure: failedURI (We don't have a URI for history APIs.)"

RESOLVED FIXED in mozilla15

Status

()

Core
Document Navigation
--
critical
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: Jesse Ruderman, Assigned: O. Atsushi (Torisugari))

Tracking

(Blocks: 1 bug, {assertion, regression, testcase})

Trunk
mozilla15
x86_64
Mac OS X
assertion, regression, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

5 years ago
Created attachment 619468 [details]
testcase (must be local) (asserts fatally when loaded)

1. Save a copy of the testcase locally.
2. Using a debug build of Firefox, load the testcase from a file: URL.

Assertion failure: failedURI (We don't have a URI for history APIs.), at /Users/jruderman/trees/mozilla-central/docshell/base/nsDocShell.cpp:7531

Probably a regression from bug 673752. Also CCing jlebar, who fixed a few other bugs with "location = '404';" in the testcase recently.
(Reporter)

Comment 1

5 years ago
Created attachment 619469 [details]
stack trace
(Assignee)

Comment 2

5 years ago
I'm about to delete the MOZ_ASSERT, and bug 478927 is just waiting for Testcase's review. I'd like to know what hit the MOZ_ASSERT though.

If I understand correctly, the dynamic child iframe prevents the parent docshell from firing onLocationChange. In my opinion, this should not happen, no matter whtat the parent docshell is loading...
(Assignee)

Comment 3

5 years ago
(In reply to O. Atsushi (Torisugari) from comment #2)
> I'm about to delete the MOZ_ASSERT, and bug 478927 is just waiting for
> Testcase's review. I'd like to know what hit the MOZ_ASSERT though.
> 
> If I understand correctly, the dynamic child iframe prevents the parent
> docshell from firing onLocationChange. In my opinion, this should not
> happen, no matter whtat the parent docshell is loading...

Well, no, please forget this comment.
(Assignee)

Comment 4

5 years ago
Created attachment 619869 [details] [diff] [review]
Fix v1

It seems to me that 

> document.createElement("iframe");

will set the iframe docshell's initial load type |LOAD_ERROR_PAGE|. This kind of "Like father, like son" strategy is dangerous. I'm not too sure setting LOAD_CMD_HISTORY/LOAD_CMD_RELOAD is safe, but at least LOAD_ERROR_PAGE is destructive.
(Assignee)

Comment 5

5 years ago
Umm, I have no idea how to write the unit test for this bug. attachment 619468 [details] depends on synchronous fallback of NS_ERROR_NOT_FOUND, but bug 282432's fix will make the testcase invalid.
(Assignee)

Updated

5 years ago
Attachment #619869 - Flags: review?(bugs)
Comment on attachment 619869 [details] [diff] [review]
Fix v1

Hmm, is this really the problem. Or do we end up having
parent docshell being loaded while child docshell hasn't started the load yet.
Could we cancel the load in the child in that case?
(Assignee)

Comment 7

5 years ago
(In reply to Olli Pettay [:smaug] from comment #6)
> Hmm, is this really the problem. Or do we end up having
> parent docshell being loaded while child docshell hasn't started the load
> yet.

Probably both are problems. I think we should cancel such a load, if possible. And <about:neterror> may want to use iframes in the future.
(Assignee)

Comment 8

5 years ago
> And <about:neterror> may want to use iframes in the future.
e.g. bug 637619 (maybe bug 157531).
Comment on attachment 619869 [details] [diff] [review]
Fix v1

Please file a followup to actually cancel child shell loads when parent is in error
Attachment #619869 - Flags: review?(bugs) → review+
(Assignee)

Comment 10

5 years ago
Filed: bug 751137
(Assignee)

Updated

5 years ago
Keywords: checkin-needed

Updated

5 years ago
Assignee: nobody → torisugari
https://hg.mozilla.org/integration/mozilla-inbound/rev/483acaa66ef1

Should this have a test?
Flags: in-testsuite?
Keywords: checkin-needed
Target Milestone: --- → mozilla15
https://hg.mozilla.org/mozilla-central/rev/483acaa66ef1
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(Assignee)

Comment 13

5 years ago
Created attachment 621072 [details]
testcase2 (NS_ERROR_UNKNOWN_PROTOCOL)

NS_ERROR_UNKNOWN_PROTOCOL is also synchronous, and I guess nobody will insist that asyncOpen should success, since we can't create nsIChannel object. Besides, this should work (or fail) both on local and on the web.
You need to log in before you can comment on or make changes to this bug.