1553436 - A variable can no longer be named 'u2f' since Firefox 67.0

Status: VERIFIED FIXED

(Core :: DOM: Web Authentication, defect)

Description

[artur]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36

Steps to reproduce:

window.u2f='foo';
alert(u2f);

https://jsfiddle.net/6cewp2Lj/

Actual results:

alert says "[object U2F]"

Expected results:

alert says "foo"

This surely breaks the whole web

Comment 1

[artur]

To slightly elaborate: This breaks many Vaadin and GWT apps because the minifier quite quickly starts using u2f as a function or variable name. One example is https://demo.vaadin.com/sampler/ which has stopped working in Firefox 68.0 as it now tries to do someElement.setAttribute(U2F {},true) instead of someElement.setAttribute('aria-hidden', true).

This case also works differently than most (all?) other reserved words, e.g.

window.XPathResult='foo';
alert(XPathResult);
window.SecurityPolicyViolationEvent='foo';
alert(SecurityPolicyViolationEvent);
WebAssembly='foo'
alert(WebAssembly);

all show 'foo'. Is there a reason for this?

Comment 2

[Sylvestre Ledru [:Sylvestre]]

[Tracking Requested - why for this release]:
Might be a severe regression

Comment 3

[Sylvestre Ledru [:Sylvestre]]

jcj, rings a bell ?

Comment 4

[Calixte Denizet (:calixte)]

In using mozregression, I get:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=67251e93f756baf940c1ddc9a382b35b76dd4f75&tochange=e27fc0c01a979c6b8a423846e0461bdebe70eef4

Comment 5

[Marco Castelluccio [:marco]]

The regression range is known now (see comment 4), it was caused by bug 1539541, uplifted to 67.

Comment 6

[J.C. Jones [:jcj] (he/they)]

There's a potential fix that bz and I are considering, but travel today/tomorrow is in my way from making progress on it. cc-ing in bz.

Comment 7

[Boris Zbarsky [:bzbarsky]]

"u2f" is not like "XPathResult" (which doesn't have any methods on it, note); it's more like "document" or "location" or "navigator", right?

That said, we may be able to make it [Replaceable] to fix this; that should be normal procedure for adding new properties to Window. Except that would then break all sites using the Google u2f polyfill, because that polyfill is quite poorly written and starts replacing properties on the u2f object with garbage that only works in Chrome. Like jcj said, we're trying to figure out whether we can prevent that somehow...

Comment 8

[Timea Zsoldos [:zstimi/tzsoldos], Desktop QA]

I have reproduced this issue using Firefox 68.0a1 (2019.05.13) on Win 10 x64.
I can confirm this issue is fixed, I verified using Firefox 69.0a1 (2019.05.27) Win 10 x64, Ubuntu 16.04 x64 and macOS 10.14.5.

Comment 9

[Timea Zsoldos [:zstimi/tzsoldos], Desktop QA]

I can confirm this issue is fixed, I verified using Firefox 68.0b5 on Win 10 x64, Ubuntu 16.04 x64 and macOS 10.14.5.

Comment 10

[Liz Henry (:lizzard) (relman/hg->git project)]

Timea, best not to change the 67 affected flag to wontfix. This may be something we are considering for a dot release (that's why it's marked as tracking+ for 67).

Comment 11

[Liz Henry (:lizzard) (relman/hg->git project)]

Oh, no I see why you changed it -- it's because it was wontfixed for 67 in bug 1551282. But, I'm going to set it back to affected in both bugs since there is an uplift request to bring a fix to release 67 in bug 1551282 and this issue seems potentially severe enough for dot release.

Comment 12

[Liz Henry (:lizzard) (relman/hg->git project)]

Marking wontfix for 67.0.5 from discussion in bug 1551282.

Comment 13

[Julien Cristau [:jcristau]]

fixed in 67.0.2

Comment 14

[Timea Zsoldos [:zstimi/tzsoldos], Desktop QA]

I can confirm this issue is fixed, I verified using Firefox 67.0.2 on Win 10 x64, Ubuntu 18.04 x64 and macOS 10.14.5.