Closed
Bug 1340333
Opened 8 years ago
Closed 8 years ago
stylo: stop doing permission manager lookups for browser frames during stylo traversal
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
mozilla54
Tracking | Status | |
---|---|---|
firefox54 | --- | fixed |
People
(Reporter: bholley, Assigned: bholley)
References
Details
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
smaug
:
review+
|
Details | Diff | Splinter Review |
Assignee | ||
Comment 1•8 years ago
|
||
MozReview-Commit-ID: Gm0oYaSKpUY
Attachment #8838315 -
Flags: review?(bugs)
Comment 2•8 years ago
|
||
Comment on attachment 8838315 [details] [diff] [review]
Precompute the browser permission at frame element creation time. v1
> nsGenericHTMLFrameElement(already_AddRefed<mozilla::dom::NodeInfo>& aNodeInfo,
> mozilla::dom::FromParser aFromParser)
> : nsGenericHTMLElement(aNodeInfo)
> , nsBrowserElement()
> , mNetworkCreated(aFromParser == mozilla::dom::FROM_PARSER_NETWORK)
> , mIsPrerendered(false)
> , mBrowserFrameListenersRegistered(false)
> , mFrameLoaderCreationDisallowed(false)
>+ , mBrowserFrameAllowed(false)
> {
>+ // Decide at creation time whether to allow browser frames. This is a bit
>+ // sloppy, since the principal of an element may change if it gets adopted
>+ // to another same-origin global, or the permission might be added in the
>+ // interim. But it seems reasonable to require that an origin have the
>+ // browser permission at the time a frame is created in order for that frame
>+ // to be a browser.
>+ nsIPrincipal *principal = NodePrincipal();
Nit, nsIPrincipal* principal = NodePrincipal()
(though, I would just use NodePrincipal() as param)
I'm tiny bit worried about the performance. Normally frames/iframes don't end up calling TestPermissionFromPrincipal, and
I don't have any idea whether TestPermissionFromPrincipal is fast or slow.
So, please profile iframe creation time a bit and see how much slower it becomes with this new patch.
Assuming there isn't significant performance regression, r+. If there is, we need to figure out something else.
Attachment #8838315 -
Flags: review?(bugs) → review+
Comment 3•8 years ago
|
||
On option would be to move the permission check to happen ::AfterSetAttr in case nsGkAtoms::mozbrowser is set, and store mBrowserFrameAllowed there. By default mBrowserFrameAllowed would be false.
Comment 4•8 years ago
|
||
I think I'd prefer to have the check in ::AfterSetAttr. Then we wouldn't need to check !GetBoolAttr(nsGkAtoms::mozbrowser in nsGenericHTMLFrameElement::GetReallyIsBrowser.
Comment 5•8 years ago
|
||
But if there isn't performance regression with the patch, it is fine too.
Assignee | ||
Comment 6•8 years ago
|
||
MozReview-Commit-ID: Gm0oYaSKpUY
Attachment #8838332 -
Flags: review?(bugs)
Assignee | ||
Updated•8 years ago
|
Attachment #8838315 -
Attachment is obsolete: true
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → bobbyholley
Updated•8 years ago
|
Attachment #8838332 -
Flags: review?(bugs) → review+
Comment 7•8 years ago
|
||
oops, ::mozbrowser, not ::browser
Assignee | ||
Comment 8•8 years ago
|
||
Pushed by bholley@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/fa1e057ae6fd
Eagerly compute whether a frame is really a browser. r=smaug
Comment 10•8 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox54:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•