noopener causes slowdown
Reported by
akh...@dropbox.com,
Jun 12 2017
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36 Steps to reproduce the problem: [filing at the request of nasko@] so we recently started noticing that noopener on chrome causes hundreds of ms of delay because I think Chrome will no longer reuse the render process. What is the expected behavior? What went wrong? This is not great because it makes noopener not a simple primitive we can apply everywhere. The current recommendation is that "put noopener for untrusted or x-origin links only since by default it slows things down". This is ripe for mistakes and errors. It would be nicer if the browser itself saw that the popup is same origin and reused the render process, if possible Did this work before? N/A Does this work in other browsers? N/A Chrome version: 59.0.3071.86 Channel: stable OS Version: OS X 10.12.5 Flash Version:
,
Jun 13 2017
,
Jun 13 2017
mkwst@: I think part of the motivation of noopener is to get the new process (e.g., for performance isolation), right? I'd be skeptical about avoiding that in the same-site case.
,
Jun 14 2017
We use the same logic for `noopener` that we used for `noreferrer`. I imagine you'd see similar behavior patterns for that mechanism. I also agree with Charlie; it's not clear to me that it's a good idea to differentiate between same-origin and cross-origin pages when considering whether to spin up a new process. When you say "hundreds of ms of delay", is that just to open the new window? Or are you seeing persistent slowdown outside that direct context?
,
Jun 14 2017
Delay in opening new window.
,
Jun 14 2017
In general, the window opening should not be affected, as the codepath I think is independent from the noopener flag. Grabbing a trace from two links, one with and one without noopener should give us some data as to what is slower. However, I couldn't find traces for the window.open() call, so it might be a good idea to add those.
,
Jun 19 2017
,
Jun 19 2017
Dev, is this something that changed in M59 in particular? Or is this a general problem with `noopener` that you're just now reporting?
,
Jun 19 2017
just dug in more .. I thought this was a recent regression but its not. My apologies. In any case, this isn't a big deal since we have stopped using for noopener for popups in same origin. Its not great though since this makes noopener a harder to use primitive.
,
Jun 19 2017
Thank you for providing more feedback. Adding requester "mkwst@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 20 2018
Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by nasko@chromium.org
, Jun 12 2017