Closed Bug 1553436 Opened 1 year ago Closed 1 year ago

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

Categories

(Core :: DOM: Web Authentication, defect)

defect
Not set

Tracking

()

VERIFIED FIXED
mozilla69
Tracking Status
firefox-esr60 --- unaffected
firefox67 + verified
firefox67.0.1 --- wontfix
firefox68 + verified
firefox69 --- verified

People

(Reporter: artur, Assigned: bzbarsky)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression, site-compat, Whiteboard: [fixed by bug 1551282])

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

Component: Untriaged → DOM: Device Interfaces
Product: Firefox → Core

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?

Summary: A variable can no longer be named 'u2f' since Firefox 68.0 → A variable can no longer be named 'u2f' since Firefox 67.0

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

Keywords: regression
Version: 63 Branch → unspecified

jcj, rings a bell ?

Flags: needinfo?(jjones)
Status: UNCONFIRMED → NEW
Ever confirmed: true

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

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.

Flags: needinfo?(jjones)

"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...

Depends on: 1551282
Component: DOM: Device Interfaces → DOM: Web Authentication
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Whiteboard: [fixed by bug 1551282]
Target Milestone: --- → mozilla69

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.

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.

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).

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.

Blocks: 1552450
Assignee: nobody → bzbarsky

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.

Status: RESOLVED → VERIFIED
Blocks: 1556853
Duplicate of this bug: 1556853
You need to log in before you can comment on or make changes to this bug.