[blink-dev] Intent to Implement and Ship : Support "noreferrer" for window.open()

[박중헌]

Contact emails

pjh...@gmail.com, jh718...@samsung.com

Explainer

https://github.com/whatwg/html/pull/4331

Spec

Specification: https://html.spec.whatwg.org/multipage/window-object.html

Summary

window.open's "noreferrer" option's ain is not to pass the HTTP referrer header.

Users can use "noreferrer" option in window.open if they want not to leak referrer info.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

This feature will be supported on all platforms.

Risks

Interoperability and Compatibility

Edge: No signals

Firefox:  No signals

Safari: No signals

Ergonomics

N/A

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Yes. They are located in https://github.com/web-platform-tests/wpt/tree/master/html/browsers/the-window-object.

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=931207

Link to entry on the feature dashboard

N/A

[박중헌]

For your information,

Current bug tracking: https://bugs.chromium.org/p/chromium/issues/detail?id=931207

Current gerrit location: https://chromium-review.googlesource.com/c/chromium/src/+/1541376

2019년 3월 29일 (금) 오전 11:20, 박중헌 <pjh...@gmail.com>님이 작성:

Contact emails

pjh...@gmail.com, jh718...@samsung.com

Explainer

https://github.com/whatwg/html/pull/4331

Spec

Specification: https://html.spec.whatwg.org/multipage/window-object.html

Summary

window.open's "noreferrer" option's ain is not to pass the HTTP referrer header.

Users can use "noreferrer" option in window.open if they want not to leak referrer info.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

This feature will be supported on all platforms.

Risks

Interoperability and Compatibility

Edge: No signals

Firefox:  No signals

Safari: No signals

Ergonomics

N/A

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Yes. They are located in https://github.com/web-platform-tests/wpt/tree/master/html/browsers/the-window-object.

[Boris Zbarsky]

On 3/28/19 10:20 PM, 박중헌 wrote:
> https://bugs.chromium.org/p/chromium/issues/detail?id=931207

I took a quick look at the proposed changes, and unless I am missing
something, this has the same problem as Chrome's implementation of
"noopener" in window.open: all the other features go missing.

That is, if a page does:

window.open("", "", "noopener");

the resulting window has no tab bar, no back/forward/reload buttons, no
editable URL field. I expect the new "noreferrer" implementation to
have the same problem, unless I am seriously missing something.

In practice that means the value is not really usable by web pages,
because the result acts "broken" from the user's point of view.

On the spec side, this is https://github.com/whatwg/html/issues/1902 and
https://github.com/whatwg/html/pull/3297 but there was a bit of a lack
of response from Mike and the CSSOM end of things is a mess no matter
what, so things haven't gone very far there in the last 2+ years.
Firefox just went ahead and unilaterally did the sane thing here in
https://bugzilla.mozilla.org/show_bug.cgi?id=1419960 and I would suggest
you do the same if you want people to actually use this functionality.

-Boris

[박중헌]

Hmm, I just checked the behavior of chromium version 72.0.3626.109 on Ubuntu 18.04.

And whenever I put some option at third parameter position,

window.open("","", here),

no matter what the option is, the behavior is as you said, Boris.

e.g. url in url bar is not editable, ...

so, merely window.open("","","width=500") behaves exactly same,

so it's not the matter of "noopener" in chromium I think.

When I see https://hg.mozilla.org/mozilla-central/rev/7122e56941ef, you commented above,

Mozilla had an issue related with the tokenizing way of noopener which is

"splitting on commas and applying HTML whitespace trimming" somehow.

I'm planning to apply that "splitting on commas and applying HTML whitespace trimming"

to tokenizing way of window features string in chromium also in separate CL,

but it has nothing to do with this issue in chromium case I guess.

I guess this CL https://chromium-review.googlesource.com/c/chromium/src/+/1541376

could be applied regardless the issue you described above in this thread,

and the behavior shown when third argument is specified should be handled 

as a separate bug I think.

If I miss out something, please let me know,

and thank you for your feedback:)

[Boris Zbarsky]

On 3/29/19 2:08 AM, 박중헌 wrote:
> so, merely window.open("","","width=500") behaves exactly same,

Yes, that is the historical behavior of the window feature options. It
makes some sense (maybe) for the case of opening a window where you
really want to control its visual presentation, which is what those
options are all about. So you specify exactly the options you want, in
that world.

> so it's not the matter of "noopener" in chromium I think.

My point is that this behavior doesn't make sense if you want to say
"just give me a normal window, but with noopener behavior". Same for
"noreferrer". These aren't presentation options, and should not affect
the way the window _looks_.

> When I see https://hg.mozilla.org/mozilla-central/rev/7122e56941ef, you
> commented above,
> Mozilla had an issue related with the tokenizing way of noopener which is
> "splitting on commas and applying HTML whitespace trimming" somehow.

This is unrelated to the issue at hand, actually. That's talking about
the fact that, at the point this code was written, doing something like:

window.open("", "", "noopener=true");

was not supposed to lead to noopener behavior, per spec. This changed a
few months ago (Nov 2018); we haven't updated our parsing in Gecko yet
to follow the new model. That's tracked in
<https://bugzilla.mozilla.org/show_bug.cgi?id=1498211>.

> I guess this CLhttps://chromium-review.googlesource.com/c/chromium/src/+/1541376

> could be applied regardless the issue you described above in this thread,

Sure. I'm just saying that if we want authors to actually use this,
that's not enough on its own.

-Boris

[박중헌]

 My point is that this behavior doesn't make sense if you want to say 

"just give me a normal window, but with noopener behavior".  Same for 
"noreferrer".  These aren't presentation options, and should not affect 
the way the window _looks_.

> “just give me a normal window, but with noopener behavior”

Yepp, I think usually people expect this behavior from

“Noopener” and “noreferrer” too.

Then you meant that current Firefox acts as “giving user a normal window, but with noopener behavior“,

with the mozilla bug jira you specified, if I got it right.

Maybe I referred wrong patch in that mozilla jira url.

Anyway, as you said, it seems that there is no spec for that until now,

So Firefix decided to do that for now unilaterally regardless of existence of the spec for that.

Now I got your point. Thank you for your explanation, Boris:)

Because I didn’t know that that behavior is the historical one,

I didn’t get your point correctly.

Normal window with window.open (noopener or noreferrer) sounds reasonable,

And I think I could make an implementation for third argument of window.open’s behavior to act in that way,

When noopener or noreferrer is specified in it.

But I think it would be good to proceed with a new bug tracking url in chromium and a separate CL,

And I think We need to have a discussion whether we want that behavior 

In chromium before going further.

If that behavior is decided as good for chromium to have,

Then I would make a jira for it and proceed.

Thank you for your help, Boris:)

2019년 3월 29일 (금) 오후 11:03, Boris Zbarsky <bzba...@mit.edu>님이 작성:

[Joe Medley]

This looks like something we should tell web developers about. Can you please create a Chrome Status entry for this?

Joe

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEmFqRcAfFOtM557vRi0hnpU1czC%2BqHQu53CHs%3DisbuWv_hBog%40mail.gmail.com.

[박중헌]

Thank you for your suggestion, Joe,

according to your comment,

I made an github issue at https://github.com/GoogleChrome/chromium-dashboard/issues/634

for adding window.open() noreferrer option in chrome feature status.

Thank you for your help:)

2019년 4월 4일 (목) 오전 3:22, Joe Medley <jme...@google.com>님이 작성:

[Daniel Bratell]

I believe Joe referred to https://www.chromestatus.com/features where you should have an "Add feature" button next to the "Subscribe" button. It's sometimes there (it was there for me 10 minutes ago) and sometimes not so not really sure if something is being changed.

Features added to that list get tracked and documented and become more visible to web developers and others so we like it (and for web developer facing changes we demand it) when features are tracked that.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEmFqRfBuPAPaF7Dw0Bxe0JbCcRbiuZYhYx8%3Dursc_VVs29Zww%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[박중헌]

Thank you for your help, Daniel.

Then I'm afraid that I don't have the right to access to the "add features" button next to the subsribe button yet.

Because for now, I only can see the subscribe button, but "add features" button yet.

That's why I filed an issue by cicking the link "File an issue" in the bottom of "https://www.chromestatus.com/features".

I hope that the issue I registered in there are handled soon:)

2019년 4월 4일 (목) 오후 6:35, Daniel Bratell <bra...@opera.com>님이 작성:

[PhistucK]

Can someone give 박중헌 ChromeStatus edit access?

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEmFqRfMD9whXmSnU3n5EO%2BDA4DixnVgc2LmL2%2BmEdJWEOkWyw%40mail.gmail.com.

[PhistucK]

I removed Eric since he is no longer on the team and added Rick and Philip, maybe they can give edit access.

☆PhistucK

[Boris Zbarsky]

On 4/3/19 2:22 PM, 'Joe Medley' via blink-dev wrote:
> This looks like something we should tell web developers about

At risk of sounding like a broken record: this is not really usable by
web developers until the changes to make noreferrer not affect which
parts of the UI exist happen... It may be worth keeping that in mind
when deciding what the Chrome Status entry should track.

-Boris

[PhistucK]

How about a fourth parameter? Maybe even a dictionary, rather than a string.

(I realize this is not the place, but would you be on board with such a notion?)

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/47018bdf-fba6-f7ce-4dc2-63554f938072%40mit.edu.

[Boris Zbarsky]

On 4/4/19 11:36 AM, PhistucK wrote:
> How about a fourth parameter? Maybe even a dictionary, rather than a string.
> (I realize this is not the place, but would you be on board with such a
> notion?)

I don't have any obvious objections, but the current string thing works
fine in spec terms; it's just implementations that need to do it "right".

-Boris

[Johnny Stenback]

Done, pjh...@gmail.com now has edit access to chromestatus.com.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_KTj%3Dk0EhrDeqdNfdnAQZbQrs4wMQNEKzLhd%2BgYVa2_og%40mail.gmail.com.

[박중헌]

I’m afraid whether fourth parameter complys with the spec specified in

https://github.com/whatwg/html/pull/4331.

And the enbling window.open(“noreferrer”) CL, 

https://chromium-review.googlesource.com/c/chromium/src/+/1541376, 

changes noreferrer related wpt tests’ results from failure to pass, and 

the wpt tests seems to expect for "noreferrer" to be in a window feature string.

As Boris said in this thread above, in case the patch

https://bugzilla.mozilla.org/show_bug.cgi?id=1419960, 

this patch excludes noreferrer option when creating window feature options list 

to be passed for create window process.

Of course this is not specified in spec, but Mozilla decided to do that, 

so I think maybe chrome could do similar behavior as well, if decided to do that here.

I think we can do it also, by after using the “noreferrer” option here,

third_party/blink/renderer/core/page/create_window.cc

frame_request.GetResourceRequest().SetHTTPReferrer(

      SecurityPolicy::GenerateReferrer(

          active_frame->GetDocument()->GetReferrerPolicy(), completed_url,

          window_features.noreferrer

              ? Referrer::NoReferrer()

              : active_frame->GetDocument()->OutgoingReferrer()));

then remove that from window feature list which to be passed to create window process.

But this way of behavior should be decided maybe in this thread

whether it is the direction chromium would want to,

so I'd like to ask about this implementation way similar to the one Mozilla did

is ok in chromium.

And about this CL https://chromium-review.googlesource.com/c/chromium/src/+/1541376

I guess there are 2 options.

1) As a first step, support "noreferrer" with this CL to separate supporting "noreferrer"

from the traditional behavior of window.open third option for now,

and continue the discussion how to handle the traditional behavior in chromium implementation.

2) Wait to the discussion to be done, then add it to this "support noreferrer" CL

also, and enabling support "noreferrer" with that discussed behavior at once.

Either way I'd be happy:)

Thank you for giving me chrome status edit access, Phistuck and Johnny:)

2019년 4월 5일 (금) 오전 2:45, Johnny Stenback <jste...@chromium.org>님이 작성:

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACZRgz6M6qDpHRq2QfZ-jN6iHBiRb5Wjzqh%3Dg-NdzsvO%3Dfbb0w%40mail.gmail.com.

[Joe Medley]

If that's the case, then we don't need an entry yet.

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

[박중헌]

I see. For noopener and noreferrer in third argument set those things to false right before they are passed to create window process so that the window created behaves as normal, not related with traditional window behavior, would be needed to discuss I think maybe in this thread.

Firefox seems to doing it already by shipping the behavior which work as normal window at least for noopener option, so maybe chromium could do the same, it would be useful for web developers as Boris pointed out I think.

2019년 4월 5일 (금) 오전 8:33, Joe Medley <jme...@google.com>님이 작성:

[Daniel Bratell]

So implementing and shipping noreferrer for window.open() sounds good, but I agree with Boris that for them to be useful to web developers they need to be interpreted as Mozilla apparently does. I.e. they should not replace the default window setup but complement it.

I'm unclear whether that is already supported by the spec or if the spec needs changing, but regardless it would be the right thing to do.

/Daniel

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEmFqReeVqcqjNN3moA1tu_eFd3%2BxKUWw69LLypQ_U9gRRc-Qw%40mail.gmail.com.

[Daniel Bratell]

I think it needs to be a package, "noreferrer" interpreted as an addition, not a replacement, of the default window style.

/Daniel

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJUhtG-2CWGHThg7_CugeDdEs2CxSs2FpbLTVov5NM8jWgyJGg%40mail.gmail.com.

[박중헌]

Currently, when window.open's third argument is specified,

new window is shown as popup because,

1) In create_window.cc::GetWindowFeaturesFromString()

below members are set to false as default.

window_features.menu_bar_visible = false;

  window_features.status_bar_visible = false;

  window_features.tool_bar_visible = false;

  window_features.scrollbars_visible = false;

2) Then navigation_policy.cc::NavigationPolicyForCreateWindow

those members are checked to decide whether new window should be popup form.

bool as_popup = !features.tool_bar_visible || !features.status_bar_visible ||

                  !features.scrollbars_visible || !features.menu_bar_visible ||

                  !features.resizable;

So currently if window.open's third argument is specified, then at least the 5 options should be

written explicitly to see a normal window, not popup.

window.open("","","menubar status toolbar scrollbars resizable")

Maybe we could do handling like

set as_popup to false if noopener or noreferrer is specified(or both)

in navigation_policy.cc::NavigationPolicyForCreateWindow.

Then I expect that when noopener or noreferrer is specified

it would work as normal behavior maybe web developers would expect to see,

and I could include this kind of change in the enabling "noreferrer" CL,

https://chromium-review.googlesource.com/c/chromium/src/+/1541376,

as a package, not separate CLs, as Daniel said.

If the change works as I expected when I check, then I will update the CL with that behavior

and write about it in this thread.

[박중헌]

Hi, I updated this CL https://chromium-review.googlesource.com/c/chromium/src/+/1541376,

to match the handling way of "noopener" and "noreferrer" with the current Firefox's handling way of 

"noopener". It seems that Firefox is not handling "noreferrer" yet.

E.g. now window.open("url","","noreferrer") leads to normal window form, not popup,

but window.open("url","","abc noreferrer") leads to a popup form as Firefox does,

and it is same for "noopener" also.

I expect that this behavior for "noopener" and "noreferrer" has more meaning for web developers.

 

2019년 4월 5일 (금) 오후 10:32, 박중헌 <pjh...@gmail.com>님이 작성:

[Alex Russell]

LGTM1

[bratell]

LGTM2

/Daniel

[Jochen Eisinger]

lgtm3

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BSLLui4JQTKcKWn%2B%2B4NA0bxTOmOCifgbs6%3DT9zNActSqWO3rw%40mail.gmail.com.

[Philip Jägenstedt]

The spec for this is https://html.spec.whatwg.org/#window-open-steps and https://drafts.csswg.org/cssom-view/#set-up-browsing-context-features.

I can't spot the bits that would explain why setting one window feature changes the defaults for some others. Boris, does Firefox do anything like that for any of the features?

+Simon Pieters I seem to remember you poking a bit at this area in the past, do you know if we have spec bugs for the interop issues here?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALjhuifaJ%3Dkii%2BD%3D36RS8LdjbOagm%3Dj_c0zgZ%2BoKZoD2vGPC%2BA%40mail.gmail.com.

[Simon Pieters]

See

https://github.com/whatwg/html/issues/1902

https://github.com/whatwg/html/issues/2464

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25685#c3

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25722

I've tried to make improvements here in the past, but it's still a mess. :-(

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdLjcfDP3Ltshk3ZfCCBDFo32S%3DLiGxZRK6rz2k30AzWg%40mail.gmail.com.

--

Simon Pieters

https://bocoup.com/

[Boris Zbarsky]

On 4/12/19 8:52 AM, Philip Jägenstedt wrote:
> The spec for this is https://html.spec.whatwg.org/#window-open-steps and
> https://drafts.csswg.org/cssom-view/#set-up-browsing-context-features.

Note that this does not acknowledge the existence of most of the
features in question here, so if of limited utility in figuring out
actual browser behavior. Simon linked to the spec issues and whatnot
involved down-thread.

> Boris, does Firefox do anything like that for any of the features?

Anything like which?

Again, the historical behavior for the feature string is "if not empty,
default to all features disabled and enable only the ones listed in the
string". Yes, this is not a great behavior, but it's the one someone
implemented sometime in the mid-90s. Maybe we should revisit that
behavior in general, and we should definitely try to spec whatever
behavior browsers want to agree on here.

The only feature Firefox treats differently from that behavior at the
moment is "noopener". I think. That code is not exactly very clear.


-Boris

[박중헌]

Hi, I'd like to say that the 2 changes below were applied in chromium.

1) https://chromium-review.googlesource.com/c/chromium/src/+/1567133

This CL makes chromium's behavior for "noopener" to be matched with Firefox's current one.

2) https://chromium-review.googlesource.com/c/chromium/src/+/1541376

This CL makes chromium to support "noreferrer" and its behavior is in a similar manner with "noopener".

And I'm planning to add entry for "noreferrer" in Chrome Status

to tell web developers about this change.

Thank you for all of your helps:)

2019년 4월 13일 (토) 오전 12:37, Boris Zbarsky <bzba...@mit.edu>님이 작성:

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7138ab74-d7dc-7202-b150-f9a0a9ab934d%40mit.edu.

[PhistucK]

You should maybe create an issue against the HTML standard, or a pull request?

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEmFqRciAhum5yBTPo_zQj-rfKUxF99o8R8kt%2B9SOPkktR6LjQ%40mail.gmail.com.

[Anne van Kesteren]

On Thu, Apr 18, 2019 at 10:18 AM PhistucK <phis...@gmail.com> wrote:
> You should maybe create an issue against the HTML standard, or a pull request?

https://github.com/whatwg/html/pull/3297 should cover this, unless we
want to fundamentally alter the design of what specifying less than
the full set of features means.

[fri...@jeka.info]

I'm confused here.

Shouldn't the implementation of "noreferrer" be compatible with Firefox? It's not.

Using "noreferrer" or "noopener" attribute in window.open() disables sizing in Chromium and makes using this feature very problematic (for my use case just bad user experience in Chromium browsers).

Testcase is here:  https://jj.de.cool/w/

Is this intended? Is this a bug? In which browser?

j.j.

[PhistucK]

According to https://bugs.chromium.org/p/chromium/issues/detail?id=596068#c20, Firefox does not show a popup when noopener is specified, is this what you mean?

Or do you combine noopener with other tokens that control the size and that works using Firefox but not using Chrome?

☆PhistucK

[fri...@jeka.info]

• Visit  testcase https://jj.de.cool/w/
• Click all three buttons
• Compair results Firefox vs. Chrome

What I mean is:

With Firefox size of opened windows is equal.

Chromium ignors size if "noreferrer" [or "noopener"] window-feature is set.

j.j.

[PhistucK]

You can report/find an existing report via crbug.com.

Thank you!

☆PhistucK

[Eric Lawrence]

I believe you're describing https://crbug.com/1011688.