navigator.mimeTypes lies about what its properties are
Reported by
bzbar...@mit.edu,
May 5 2016
|
||||||||||||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:49.0) Gecko/20100101 Firefox/49.0
Example URL:
Steps to reproduce the problem:
Compare the following three values:
1) navigator.mimeTypes["application/x-shockwave-flash"] !== undefined
2) "application/x-shockwave-flash" in navigator.mimeTypes
3) Object.getOwnPropertyNames(navigator.mimeTypes).indexOf("application/x-shockwave-flash")
What is the expected behavior?
Either the results are false, false, -1, or the results are true, true, some-nonnegative-number.
What went wrong?
The results are true, true, -1.
In other words, Object.getOwnPropertyNames is lying. Note that this is not due to the property being on the prototype: `"application/x-shockwave-flash" in navigator.mimeTypes.__proto__
false` returns false.
Does it occur on multiple sites: N/A
Is it a problem with a plugin? N/A
Did this work before? N/A
Does this work in other browsers? Yes
Chrome version: 52.0.2716.0 (Official Build) dev (64-bit) Channel: n/a
OS Version: OS X 10.10
Flash Version: Shockwave Flash 21.0 r0
,
May 6 2016
,
May 6 2016
This is because navigator.mimeTypes is not a standard array or object. If something tries to get a key of this object that it does not have, it runs an internal function to resolve it from a mime type. This means that navigator.mimeTypes resolves the values with a function if not found first, so it does not actually have the properties with normal names instead it resolves them if it cannot find them.
,
May 8 2016
My point is that this is a spec violation. This isn't a standard array or object, but its behavior is defined by https://html.spec.whatwg.org/multipage/webappapis.html#mimetypearray and Chrome is not following the spec here.
,
May 8 2016
Yes, this is quite a bad violation of web specs (not to mention fairly basic JavaScript invariants). There are many parts of the platform that are not "standard arrays or objects" but still follow the specs. Reopening and re-triaging to the DOM team. allada@, if you have no intention of fixing this please unassign yourself so that it can get looked at by the DOM team.
,
May 9 2016
,
May 10 2016
,
May 30 2016
,
Jun 1 2016
Moving this nonessential bug to the next milestone. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 11 2016
This issue has been moved once and is lower than Pri-1. Removing the milestone. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 11 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 13 2017
Note: "application/x-shockwave-flash" isn't available nowadays. Replace it in the reproduce steps with "application/pdf".
,
Jul 14 2017
,
Jul 18 2017
|
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by nyerramilli@chromium.org
, May 5 2016Components: Platform>DevTools
Labels: -Type-Compat M-52 OS-Linux OS-Windows Type-Bug
Status: Untriaged (was: Unconfirmed)