Closed
Bug 921959
Opened 11 years ago
Closed 10 years ago
nsIWebNavigation::reload(LOAD_FLAGS_ALLOW_MIXED_CONTENT) fails in e10s
Categories
(Core :: DOM: Navigation, defect, P2)
Core
DOM: Navigation
Tracking
()
RESOLVED
FIXED
mozilla34
Tracking | Status | |
---|---|---|
e10s | + | --- |
People
(Reporter: markh, Assigned: jimm)
References
(Blocks 1 open bug)
Details
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
jimm
:
review+
|
Details | Diff | Splinter Review |
browser_bug822367.js and browser_bug902156.js both are mixed-content tests and call reload() with LOAD_FLAGS_ALLOW_MIXED_CONTENT. These tests fail and the test output includes:
0:08.33 TEST-INFO | chrome://mochitests/content/browser/browser/base/content/test/general/browser_bug902156.js | Console message: [JavaScript Error: "NS_ERROR_ILLEGAL_VALUE: Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIWebNavigation.reload]" {file: "chrome://global/content/browser-child.js" line: 163}]
Instrumenting browser-child.js shows that it only seems to fail when the flags are LOAD_FLAGS_ALLOW_MIXED_CONTENT. Haven't dug any deeper than this!
Updated•11 years ago
|
Flags: needinfo?(tanvi)
Comment 1•11 years ago
|
||
LOAD_FLAGS_ALLOW_MIXED_CONTENT is used when a user clicks on the shield doorhanger and decides to disable mixed content blocking protection on a page. When the user does this, we reload the page with this flag. When we detect this flag on reload, we set something called the MixedContentChannel to the current channel:
https://mxr.mozilla.org/mozilla-central/source/docshell/base/nsDocShell.cpp#9634
When deciding whether to allow or block mixed content, we compare the MixedContentChannel against the current channel to see if the user disabled protection for the page:
https://mxr.mozilla.org/mozilla-central/source/docshell/base/nsDocShell.cpp#5505
Unfortunately, I won't be able to look into these e10s failures anytime soon.
Flags: needinfo?(tanvi)
Updated•11 years ago
|
tracking-e10s:
--- → +
Updated•11 years ago
|
Blocks: old-e10s-m2
Updated•10 years ago
|
Assignee: nobody → jmathies
Priority: -- → P2
Assignee | ||
Comment 2•10 years ago
|
||
Appears we fixed this at some point, these tests pass for me with --e10s.
Attachment #8479948 -
Flags: review?(wmccloskey)
Assignee | ||
Comment 3•10 years ago
|
||
Assignee | ||
Comment 4•10 years ago
|
||
(In reply to Jim Mathies [:jimm] from comment #3)
> try push:
> https://tbpl.mozilla.org/?tree=Try&re..
push w/properly formatted --e10s flags -
https://tbpl.mozilla.org/?tree=Try&rev=a69f03edd2d8
Assignee | ||
Comment 5•10 years ago
|
||
(In reply to Jim Mathies [:jimm] from comment #4)
> (In reply to Jim Mathies [:jimm] from comment #3)
> > try push:
> > https://tbpl.mozilla.org/?tree=Try&re..
>
> push w/properly formatted --e10s flags -
>
> https://tbpl.mozilla.org/?tree=Try&rev=a69f03edd2d8
Hrm, unfortunately none of the bc runs got far enough to actually run these tests. They should show up in bc1.
Attachment #8479948 -
Flags: review?(wmccloskey) → review+
Assignee | ||
Comment 6•10 years ago
|
||
Attachment #8479948 -
Attachment is obsolete: true
Attachment #8480805 -
Flags: review+
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Comment 7•10 years ago
|
||
Flags: in-testsuite+
Keywords: checkin-needed
Comment 8•10 years ago
|
||
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
You need to log in
before you can comment on or make changes to this bug.
Description
•