Bug 151782 – Fidelity.com login page does not show username and password field

• Component: Evangelism
• Status: RESOLVED WONTFIX

Created attachment 266488 [details]
fidelity.com log-in window on WebKit nightly r192882 (OS X 10.11)

Any authentication request on fidelity.com, if not already logged in, will bring up a username field and a password field. The username field doesn't show a box to accept input. This makes logging into fidelity.com impossible on WebKit nightly. WebKit nightly version r192882. The page renders correctly on Safari.

[Daniel Bates]

Created attachment 267267 [details]
[WebArchive] https://oltx.fidelity.com/ftgw/fbc/ofsummary/defaultPage

For historical preservation, a web archive of <https://oltx.fidelity.com/ftgw/fbc/ofsummary/defaultPage> as it appeared on 12/13/2015. This archive was created using Safari Version 9.0.2 (10601.3.9) on OS X 10.10.5 (14F1509).

[Daniel Bates]

Confirmed the issue with Mac nightly r194016. I am using Safari Version 9.0.2 (10601.3.9).

[Daniel Bates]

The issue is that plugins are not loaded from /Library/Internet Plugins when using the nightly. Note that plugins are loaded if placed in ~/Library/Internet Plugins.

Loading <https://oltx.fidelity.com/ftgw/fbc/ofsummary/defaultPage> in Mac nightly r194016 I see a JavaScript ReferenceError in the Web Inspector console:

[Error] ReferenceError: Can't find variable: temp
    deviceprint_software (device_print.js:216)
    add_deviceprint (device_print.js:540:156)
    post_deviceprint (device_print.js:484)
    (anonymous function) (retailWidget.js:7)
    c (jquery-1.10.2.min.js:4:26042)
    fireWith (jquery-1.10.2.min.js:4:26842)
    ready (jquery-1.10.2.min.js:4:3317)
    q (jquery-1.10.2.min.js:4:723)

As indicated by the error, the code in deviceprint_software() (defined in <https://login.fidelity.com/ftgw/pages/js/common/device_print.js>) has a correctness issue on line 216 - it assumes the variable temp has been defined and performs a string concatenation of the value of temp and the empty string (temp += "";). We only reach line 216 when no plugins are loaded (i.e. navigator.plugins.length == 0) and navigator.mimeTypes.length > 0.

[Alexey Proskuryakov]

> The issue is that plugins are not loaded from /Library/Internet Plugins when using the nightly. Note that plugins are loaded if placed in ~/Library/Internet Plugins.

I cannot reproduce this.

> i.e. navigator.plugins.length == 0

This sounds related to bug 149014.

[Brent Fulgham]

(In reply to comment #4)
> > The issue is that plugins are not loaded from /Library/Internet Plugins when using the nightly. Note that plugins are loaded if placed in ~/Library/Internet Plugins.
> 
> I cannot reproduce this.
> 
> > i.e. navigator.plugins.length == 0
> 
> This sounds related to bug 149014.

Does this problem happen with Firefox? If not, then this is probably not related to Bug 149014, since we now match Firefox's plugin disclosure behavior.

It's also weird that things work if you put the plugins in the user's personal Library folder. That makes me wonder if this is some kind of Sandbox change.

[Daniel Bates]

(In reply to comment #3)
> The issue is that plugins are not loaded from /Library/Internet Plugins when
> using the nightly. Note that plugins are loaded if placed in
> ~/Library/Internet Plugins.
> 

Disregard this remark.

[Daniel Bates]

(In reply to comment #5)
> (In reply to comment #4)
> > > [...]
> > 
> > > i.e. navigator.plugins.length == 0
> > 
> > This sounds related to bug 149014.
> 
> Does this problem happen with Firefox?

On the same machine using Mac Firefox version 42.0, navigator.plugins.length returns 5:

> navigator.plugins.length
5
> navigator.plugins
PluginArray { 0: Plugin, 1: Plugin, 2: Plugin, 3: Plugin, 4: Plugin, Adobe Acrobat NPAPI Plug-in, Version 11.0.13: Plugin, Default Browser Helper: Plugin, Shockwave Flash: Plugin, iPhotoPhotocast: Plugin, 1 more… }

And accessing <https://oltx.fidelity.com/ftgw/fbc/ofsummary/defaultPage> shows a username and password field (as expected).

[Daniel Bates]

Looking at <https://login.fidelity.com/ftgw/pages/js/common/device_print.js>, Fidelity.com is using the navigator.plugins data as a way to fingerprint a device, which is a behavior that we do not want to support and mitigated in the patch for bug #149014.

As aforementioned in the second paragraph of comment #3, Fidelity.com has a JavaScript error in their code such that when navigator.plugins.length == 0 a ReferenceError is thrown and this affects the display of a username and password field. Fidelity.com should update their code to address this issue.

[Daniel Bates]

CC'ing Jonathan Davis, Web Technology Evangelist, as he may be able to help reach out to Fidelity.com to address the JavaScript error in their code.

[Alexey Proskuryakov]

FWIW, I find other instances of this code when I search the internet for this script's content. Those are not live installations, but those are likely not searchable if they exist.

[Brent Fulgham]

(In reply to comment #7)
> (In reply to comment #5)
> > Does this problem happen with Firefox?
> 
> On the same machine using Mac Firefox version 42.0, navigator.plugins.length
> returns 5:
> 
> > navigator.plugins.length
> 5

I'm sorry -- I meant, "Does Mac Firefox also lack the login box needed for the user name"?

[Alexey Proskuryakov]

<rdar://problem/28213657>