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 :(
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.
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....
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.
You need to log in before you can comment on or make changes to this bug.