Site's javascript not working since Firefox update today, works on old Firefox and other browsers

REOPENED
Unassigned

Status

()

Core
DOM
REOPENED
4 years ago
4 years ago

People

(Reporter: Conor O'Sullivan, Unassigned)

Tracking

32 Branch
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
Created attachment 8489907 [details]
firefox_32_bug.PNG

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36

Steps to reproduce:

Javascript on our page, using isotope.metafizzy.co library, has stopped working today, and all js not working. Continues to work on other browsers. Cannot resolve by console listing.
Site is adaptemy.com, login with test user (John_1, Admin1), then load page
https://www.adaptemy.com/courses/topiclist/9?group=5


Actual results:

Grid layout does not load. Javascript dies. No other functions work.


Expected results:

See any other browser behaviour.
Grid layout loads, with transition animations.
Is it possible the website was just modified and this no longer repros?

I could reproduce this and was bisecting, then got some PHP error pages and now I no longer see the problem :(
(Reporter)

Comment 2

4 years ago
Thanks. It was a conflict caused by the library https://github.com/shawnbot/aight
This library ensures backwards compatability to IE8.
We now load this library only when the client is using IE, so Firefox is working well for us.

In previous versions of Firefox, this library still works, so not sure what the problem is.

Comment 3

4 years ago
As it's a conflict with a lib for IE8 hacks, I close the bug report.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
No, hold on a sec.  Loic, if sites are using this library and we're now breaking it, that's a problem.  We need to figure out whether this breakage is accidental or whether the library just needs to get fixed....

Conor, is there a page that still shows the problem?  Were there any JS errors you saw reported when the problem was happening?
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WORKSFORME → ---
As I said in comment 1, I was in the middle of bisecting when it got fixed. But I saw something like this in the console:

element.currentStyle is undefined

I think it also failed with the JITs disabled. The regression range was like this:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e86a0d92d174&tochange=e017c15325ae

But I'm not sure; it could have regressed a few days before this...
Jan, thanks!

That pushlog has the window webidl bindings landing.

element.currentStyle is an IE-ism that we in fact do not implement.

What's happening here is that the library checks for "getComputedStyle" support by testing "'getComputedStyle' in Window.prototype" and polyfills it using .currentStyle if not present, but per current Web IDL spec this method is supposed to be on the window object itself, not on the prototype.  In bug 789261 we aligned with the spec on this issue, which is what's causing problems here.

I filed https://github.com/shawnbot/aight/issues/39

Peter, I wonder whether for web compat we should consider defining at least the window methods on both the object itself _and_ on the prototype or something....
Blocks: 789261
(Reporter)

Comment 7

4 years ago
If you still need to see the broken version, you can see it on our dev site:
www2.adaptemy.com
Login: John_1, Admin1
Broken page is:
http://www2.adaptemy.com/courses/topiclist/9?group=6
Conor, thank you very much for setting that up!

I can confirm that flipping the GlobalPropertiesAreOwn() boolean back to false fixes that site, so comment 6 is a correct analysis of what's going on here.
Component: JavaScript Engine → DOM
You need to log in before you can comment on or make changes to this bug.