User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 Build ID: 20180220103456 Steps to reproduce: Using Nightly, create a brand new profile. Go to https://www.battlefield.com/en-gb/news/update-notes/apocalypse-update Actual results: When the page renders, it displays but the links that should be part of pull-down menus at the top of the page are instead displayed as a list of separate links. Expected results: The top of the page has pull-down menus with links on them. The page correctly works with Firefox Release 58.0.2 (64-bit), Firefox Beta 59.0b11 (64-bit), Firefox Developer 59.0b11 (64-bit), Chrome 64.0.3282.167 (Official Build) (64-bit). This is on a Windows 7 (64-bit) system. User "Are You A Wizard?" on Windows 10 reports the page works fine with Edge, but not with Firefox Nightly (whither uBlock Origin is enabled or disabled). It's the first reply at http://forums.mozillazine.org/viewtopic.php?p=14792736#p14792736
On mozillaZine Forums (thread I linked to) in Description had a post saying this is a regression of Bug 1406825.
regression window: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2a26976b3f165d16d5662c4e29513ec30ce36443&tochange=463c2d88ae6823e6a5f0275a28299567ccfde553
Status: UNCONFIRMED → NEW
Component: Untriaged → DOM
Ever confirmed: true
Product: Firefox → Core
Changing dom.webcomponents.customelements.enabled to False causes the page to render correctly. (Thank you, Alice0775, for that hint.)
As web components are still under active development, I'm wondering if this is invalid. @smaug, agree? Or would you want to keep this to test our implementation against?
better to track it at least.
It's something with Polymer, you can see this also in their own demo site: https://shop.polymer-project.org/
The Polymer demo site with Firefox 61 beta 4 now works in the same way with dom.webcomponents.customelements.enabled enabled as it does when it is disabled, and works the same way as in other browsers. However the battlefield.com site still renders incorrectly when dom.webcomponents.customelements.enabled is set to true
What is left there is basically bug 1478959, since the web sites are using the same library, which relies on a bug in Chrome.
Status: NEW → RESOLVED
Last Resolved: 7 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1478959
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.