[Chrome 65 regression] `window.open(... , null)` and `window.open(... , undefined)` have different opening behavior
Reported by
b...@mixmax.com,
Mar 10 2018
|
|||||||||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.146 Safari/537.36
Steps to reproduce the problem:
1. Create test.html with the following source:
<html>
<body>
<button onClick="javascript:window.open('https://example.com', null);">click this twice and it'll open in the same tab</button>
<button onClick="javascript:window.open('https://example.com', undefined);">click this twice and it'll open in different tabs tab</button>
</body>
</html>
2. Click the button #1 twice
3. Click the button #2 twice
What is the expected behavior?
Clicking the button #1 a second time should open a NEW window and not recycle the existing window.
What went wrong?
Clicking on button #1 a second time opened "example.com" in the SAME tab as it was opened the first time.
Did this work before? N/A
Chrome version: 65.0.3325.146 Channel: stable
OS Version: OS X 10.13.2
Flash Version:
This behavior changed in Chrome 65. In Chrome 64, both buttons would always open new windows each time when clicked.
The spec (https://www.w3.org/TR/html/browsers.html#apis-for-creating-and-navigating-browsing-contexts-by-name) doesn't mention how to handle null, but intuitively it would be treated as if the parameter is omitted (ie undefined).
,
Mar 10 2018
Bisect info: 522985 (good) - 522996 (bad) https://chromium.googlesource.com/chromium/src/+log/8c631d67..88d0bb67?pretty=fuller Suspecting r522986 = 7e1caf7245ca4c0e9e709b4508ead6ac9090c02d = https://crrev.com/c/808027 by bhagirathi.s@samsung.com "Remove custom bindings for DOM API Window.open" Landed in 65.0.3290.0
,
Mar 12 2018
The latest spec is here: https://html.spec.whatwg.org/C/window-object.html#the-window-object The spec says that both of |undefiend| and |null| must fallback to "_target".
,
Mar 12 2018
,
Mar 12 2018
This is indeed an issue, but this is not that severe to mark this as ReleaseBlock-Stable. End users should be able to open any page in any tab without relying on Web API. So, there are simple workarounds. So, let me remove ReleaseBlock-Stable label.
,
Mar 12 2018
Able to reproduce the issue on Windows 7, Mac 10.13.3 & Debian Rodate using chrome M65 beta-65.0.3325.125, M66 Dev-66.0.3359.22 & M67 Canary-67.0.3368.0 as per html provided in C#0. Observed that Clicking on button #1 & Button #2, 'Example.com' opened in new tab of the same Window. Thanks..!
,
Mar 12 2018
,
Mar 12 2018
,
Mar 12 2018
,
Mar 12 2018
> The spec says that both of |undefiend| and |null| must fallback to "_target".
I couldn't find that bit in the text. As far as I can see, we have
WindowProxy? open(optional USVString url = "about:blank", optional DOMString target = "_blank", optional [TreatNullAs=EmptyString] DOMString features = "");
and https://html.spec.whatwg.org/multipage/window-object.html#window-open-steps, which says
"3. If target is the empty string, then set target to "_blank"."
(We don't seem to be properly treating the case above, but it's unrelated to the bug at hand)
As far as I can see, the M65+ behavior adheres to the spec: undefined causes |target| to be set to "_blank", and null is converted to the 4-character string "null". It also matches Safari 11 and Firefox (I tested 58 and 59). Edge 16 is the only one that behaves like Chromium did before M65. It's a behavior change that should've been handled better and broadcast more widely, but what were doing before just wasn't compatible with the spec.
The previous behavior dates back to the beginning of times: https://chromium.googlesource.com/chromium/src.git/+/5bf544f6050b79ba347f08125f07d7bf0268e11d for Blink, https://cgit.kde.org/kdelibs.git/commit/?id=e6df2107104101caaa3147858e4c6302ef335601 for WebKit. Lastly, the same transition happened between Safari 10.1 to 11, when JSC custom bindings for window.open() were dropped in https://trac.webkit.org/changeset/216615/webkit
,
Mar 13 2018
re #10: I was wrong. I misremembered that |optional| would handle |null| in the same way as |undefined|. https://heycam.github.io/webidl/#es-overloads 3.5 Overload resolution algorithm step 11.4. If optionality is "optional" and V is undefined, then: This step only handles |undefined|, so Rakuco is correct. |null| shouldn't fallback to the default value. As there is no [TreatNullAs=EmptyString], |null| should be converted to "null" of type string. Someone (including the original reporter) might want to change the spec, however, the current implementation is following the current spec so far. Then, let me close this issue as WontFix.
,
Mar 13 2018
And thank you Rakuco for correcting me. :) |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by gov...@chromium.org
, Mar 10 2018Labels: Needs-Triage-M65