deviantART watch 2.0 broken

[ThunderclawShocktrix]

Well deviantART rolled out watch 2.0 beta this weekend, figured I would try it but I immediately ran into problems, namely on the new menu bar the button labeled menu would not work also there was supposed to be a popup in the lower left corner to turn this beta on and off and that was missing also, I ended up having to use my iphone to switch it back off which more or less shows its a palemoon issue since it was working fine in mobile safari.

[Moonchild]

So... bugreport it to DA?

[ThunderclawShocktrix]

So... bugreport it to DA?

*Sigh* i did and got this response

Chris

Chris (DeviantArt)

Nov 17, 10:16 AM
Hi There,

Thanks for your inquiry. I'm afraid we do not currently support the Palemoon browser. Please be sure to switch to an officially supported browser.

http://help.deviantart.com/38/

Chris Carey
Customer Service Representative
Community Operations
ikue.deviantart.com

DeviantArt

[Moonchild]

Well, I'm afraid we can't force compatibility in something that is solely under their control.
Also, looks like it's a simple error redefining something that's already defined, which isn't allowed in strict mode:

Code: Select all

Error: SyntaxError: property name element appears more than once in object literal
Source File: http://st.deviantart.net/roses/jsmin/core.js?1447796205855
Line: 4, Column: 60
Source Code:
iew:"peek",element:"deviant_menuitem",action:"view",element:c})}}},{key:"moreCommentsClick",value:function(){this.getAct

It's the "element:c" part there.

Code: Select all

js> (function(){"use strict";({1:1,1:1})}())

I'd say it's perfectly logical that this throws in strict mode. They should clean up their code to prevent double property names/assignments in object literals, or not use strict mode without understanding all implications of doing so.

Also, if they are making it a point to not support us, then their bookmark will also be removed from the start portal. Tit for tat.

ECMAScript 5 standard, annex C:

It is a syntax error if strict mode code contains an ObjectLiteral with more than one definition of any data property (11.1.5).

So, we're perfectly in-line with ES5. If ES6 changed this then the spec is in direct conflict with itself (how on earth do they justify this for a standard that takes years to adopt?), and implementing this change would break our compatibility with the standard one way or another. DA, being a generic, large art site, should not assume or even enforce all visitors limit themselves to what they prescribe, and they should be as browser-agnostic as possible. That includes not using strict mode in case of a conflict in it, or avoiding the use of conflicting methods in standards in use altogether.

[Moonchild]

Update: it's indeed a change in ES6 that breaks with this restriction in ES5 in strict mode.
So, ES6 allows sloppy coding in strict mode. Great way to ensure code quality, people.

[ThunderclawShocktrix]

Well, I'm afraid we can't force compatibility in something that is solely under their control.
Also, looks like it's a simple error redefining something that's already defined, which isn't allowed in strict mode:

Code: Select all

Error: SyntaxError: property name element appears more than once in object literal
Source File: http://st.deviantart.net/roses/jsmin/core.js?1447796205855
Line: 4, Column: 60
Source Code:
iew:"peek",element:"deviant_menuitem",action:"view",element:c})}}},{key:"moreCommentsClick",value:function(){this.getAct

It's the "element:c" part there.

Code: Select all

js> (function(){"use strict";({1:1,1:1})}())

I'd say it's perfectly logical that this throws in strict mode. They should clean up their code to prevent double property names/assignments in object literals, or not use strict mode without understanding all implications of doing so.

Also, if they are making it a point to not support us, then their bookmark will also be removed from the start portal. Tit for tat.

ECMAScript 5 standard, annex C:

It is a syntax error if strict mode code contains an ObjectLiteral with more than one definition of any data property (11.1.5).

So, we're perfectly in-line with ES5. If ES6 changed this then the spec is in direct conflict with itself (how on earth do they justify this for a standard that takes years to adopt?), and implementing this change would break our compatibility with the standard one way or another. DA, being a generic, large art site, should not assume or even enforce all visitors limit themselves to what they prescribe, and they should be as browser-agnostic as possible. That includes not using strict mode in case of a conflict in it, or avoiding the use of conflicting methods in standards in use altogether.

could someone who is good with user scrips, do a work around?

Update: it's indeed a change in ES6 that breaks with this restriction in ES5 in strict mode.
So, ES6 allows sloppy coding in strict mode. Great way to ensure code quality, people.

also unfortunately this means at some point as this sort of slop gets more common that pale moon is going to need to be able to handle this with out breaking website UIs or it become none functional over time >.=.<


Edit: I sent them they stuff you said about which lines of code violates strict and it seems they did some as now that button sorta works I can click it and select menu options but if I just close or demises that menu then all buttons on the page break till its refreshed, which is annoying but at least its now semi usable. (the fact that this beata was also not working on IE 11 no my laptop with windows 7 may be factor as well) so it seems they are trying to fix it some.

[Moonchild]

at some point as this sort of slop gets more common that pale moon is going to need to be able to handle this

Considering this slop has now been standardized in ES6 as acceptable slop, we have no choice but to break ES5 standards compliance to adopt the more lenient of the two specs. Otherwise, yes, it will "break teh webz" as more and more web-"coders" don't care how they code.

It's totally retarded though. ES3 allowed this kind of coding. Then, ES5 actually cleaned this up and made it a more proper standard by making strict mode actually strict; it's called that way for a reason!... and now ES6 is undoing that again.

[ThunderclawShocktrix]

Considering this slop has now been standardized in ES6 as acceptable slop, we have no choice but to break ES5 standards compliance to adopt the more lenient of the two specs. Otherwise, yes, it will "break teh webz" as more and more web-"coders" don't care how they code.

It's totally retarded though. ES3 allowed this kind of coding. Then, ES5 actually cleaned this up and made it a more proper standard by making strict mode actually strict; it's called that way for a reason!... and now ES6 is undoing that again.

Agreed with everything you said here especially how dumb it is that they regressed back to not being strict anymore, also heard back from the staff again after sneding them the debugging info its bit more positive this time

"Thanks for the additional information. The IE issues are known and being worked on. As for Palemoon, we are not making it a point not to submit that browser. If it works, that's awesome! Unfortunately if not we only have the developer resources to officially support the top 4 browsers at this time. From the looks of it the same issues are affecting IE, when those are fixed it should also resolve some of the issues in Palemoon. "

I honestly understand them not having the resources to devote time just to palemoon so it seems, and I can confirm that what they have done so far has helped for palemoon at least, though not IE yet