Closed
Bug 1210459
Opened 9 years ago
Closed 9 years ago
Add originAttributes for tests that implement nsILoadContext
Categories
(Core :: Security: CAPS, defect)
Core
Security: CAPS
Tracking
()
RESOLVED
FIXED
mozilla44
Tracking | Status | |
---|---|---|
firefox44 | --- | fixed |
People
(Reporter: allstars.chh, Assigned: allstars.chh)
References
Details
Attachments
(1 file, 1 obsolete file)
5.66 KB,
patch
|
bholley
:
review+
|
Details | Diff | Splinter Review |
In Bug 1165466 I added originAttributes into nsILoadContext,
however there are also many test cases implementing nsILoadContext, which still don't have the originAttributes yet, so I'll try to add them in this bug.
Assignee | ||
Comment 1•9 years ago
|
||
Comment 2•9 years ago
|
||
Attachment #8668538 -
Flags: feedback+
Assignee | ||
Comment 3•9 years ago
|
||
fix more tests that use nsILoadContext
Attachment #8668538 -
Attachment is obsolete: true
Comment 4•9 years ago
|
||
Can we just make up and return an originAttributes based on nsILoadContext.appId/isInBrowserElement/etc when failing to ontain nsILoadContext.originAttribute in [1] instead of fixing all the nsILoadContext instances?
Comment 5•9 years ago
|
||
Assignee | ||
Updated•9 years ago
|
Attachment #8668555 -
Flags: review?(bobbyholley)
Assignee | ||
Comment 6•9 years ago
|
||
(In reply to Henry Chang [:henry] from comment #4)
> Can we just make up and return an originAttributes based on
> nsILoadContext.appId/isInBrowserElement/etc when failing to ontain
> nsILoadContext.originAttribute in [1] instead of fixing all the
> nsILoadContext instances?
That could work, but that seems only fix the crash.
That MOZ_ASSERT was put by Valentin when he took over that bug,
When I took it back I think it's a good idea to leave the assert there.
Eventually we are going to remove those appId/isInBrowser from nsIXXX and use originAttributes.
Also nsILoadContext could be implemented by JS and cpp code, so if we were going to do that, that means we need to do two JSAPI calls to get appId/isInBrowserElement.
Assignee | ||
Comment 7•9 years ago
|
||
Bobby's original comment is to return false, https://bugzilla.mozilla.org/show_bug.cgi?id=1165466#c105, if that is better I could add it back.
Updated•9 years ago
|
Attachment #8668555 -
Flags: review?(bobbyholley) → review+
Comment 9•9 years ago
|
||
There are much more tests (at least in network) that need this update. I found a few when fixing bug 1165269 and fighting bug 1165466.
Comment 10•9 years ago
|
||
Status: NEW → RESOLVED
Closed: 9 years ago
status-firefox44:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
Comment 11•9 years ago
|
||
(In reply to Honza Bambas (not reviewing) (:mayhemer) from comment #9)
> There are much more tests (at least in network) that need this update. I
> found a few when fixing bug 1165269 and fighting bug 1165466.
Now that we have bug 1210508, this should be less of an issue.
Comment 12•9 years ago
|
||
(In reply to Bobby Holley (:bholley) from comment #11)
> (In reply to Honza Bambas (not reviewing) (:mayhemer) from comment #9)
> > There are much more tests (at least in network) that need this update. I
> > found a few when fixing bug 1165269 and fighting bug 1165466.
>
> Now that we have bug 1210508, this should be less of an issue.
Quite the opposite, I'm afraid. I had the same code in the last version of my "make it work" patch (bug 1165466) and it caused failures on every call where nsILoadContext JS impl didn't define originAttributes at least as '{}'.
I think this will be exposed when I turn http cache interfaces to work with OriginAttributes. And I also think it will be part of that patch, so no worry for you, just a heads up ;)
You need to log in
before you can comment on or make changes to this bug.
Description
•