TYPO3 compatibility regression in Nightly

VERIFIED DUPLICATE of bug 892225

Status

()

Core
JavaScript Engine
VERIFIED DUPLICATE of bug 892225
4 years ago
4 years ago

People

(Reporter: ashughes, Assigned: naveed)

Tracking

({regression})

Trunk
regression
Points:
---

Firefox Tracking Flags

(firefox21 unaffected, firefox22 unaffected, firefox23 unaffected, firefox24 unaffected, firefox25 fixed)

Details

(URL)

Attachments

(2 attachments)

Created attachment 763635 [details]
Screenshot

Last night Simon Sperling alerted us to a compatibility issue with TYPO3 CMS and Firefox. Upon investigation I was able to reproduce and narrow this down to a regression somewhere in the Firefox 24 time frame. Basically the view is not rendering at all. I'll attach a screenshot so you can compare.

This does not happen in Firefox 23.0a2 or earlier.
status-firefox21: --- → unaffected
status-firefox22: --- → unaffected
status-firefox23: --- → unaffected
status-firefox24: --- → affected
tracking-firefox24: --- → ?
Keywords: regression, regressionwindow-wanted
I've traced the regression window to sometime on June 8th, unfortunately there are a lot of changes there. I'll try to regress this further.

Last good nightly: 2013-06-07
First bad nightly: 2013-06-08

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=dc8e78ed8c44&tochange=6006abb39d8e
Keywords: regressionwindow-wanted
inbound tinderbox builds are available for those dates
http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/
Tinderbox mozilla-central regression window:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c41a3e24a574&tochange=6cafe68983ca

I'll try to regress this further on inbound.
Please.  There are lots of JS changes in there too...
Tinderbox mozilla-inbound regression window:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ebae7298e381&tochange=2bd3d9bbd722

This narrows it down to four bugs. Please let me know if this needs regressing further.
I think at this point we ask the likely culprits to look.  ;)
Assignee: nobody → general
Component: Layout: View Rendering → JavaScript Engine
Good catch!  But this would be easier to figure out with steps to reproduce, a URL, or a File -> Save As -> Web page complete tarball that shows the issue.

(The URL in the image wants a login, which I don't have.)

Does this leave an error message in the Web console?
Hi Jason, sorry for leaving the test URL off this bug. I had to get permission from Simon first. 

URL: http://simon.webspace.fuse.de/typo3/
User: nightly
Pass: test

Steps:
1. Start Firefox with a new profile
2. Navigate to the URL
3. Enter the credentials and log in

Expected Results:
Typo3 dashboard should load completely

Actual Results:
Only the header for the Typo3 dashboard loads
Checking Web Console I get the following JS error in Firefox 24.0a1. I do not see this error with any other Firefox version.

> ReferenceError: sub is not defined @ http://simon.webspace.fuse.de/typo3temp/compressor/ext-all-64f9a6f742df644c9209f90842b41600.js:7
Created attachment 763696 [details]
Offending JS file

I'm not sure if it helps but the attachment is the alleged file where the error occurs. It appears to come for the Sencha library (http://www.sencha.com/)
Maybe related to bug 881782?
Possible, yes; there's various stuff in that extjs file using bareword "values" and "with(values)" which might conceivably hit this problem.  Oh, and various UA-specific codepaths, for extra fun.

Updated

4 years ago
tracking-firefox24: ? → +
Blocks: 875433
The issue likely has to do with the usage of `with(values)`. The method Array.prototype.values was added. When `values` is an Array in that WithStatement, any reference to "values" in the body statement would become `values.values`, referring to Array.prototype.values instead of the original object.
OK, so what's the plan, then?  This library (extjs) seems to be somewhat commonly used, and the most recent version of it seems to have "with(values)" all over the place.  I guess we start by disabling Array.prototype.values and reporting the problem to the extjs developers....

Comment 15

4 years ago
We've received the report of the issue and are looking at what we can do to remove the use of "with(values)".

This particular piece of code is only used in one place in Ext JS (the 2 hits out of 69 in http://cdn.sencha.com/ext/commercial/4.2.1/ext-all.js) and these date back many releases. It is used in the code generator for our XTemplate class to process user-defined sub-expressions so removing the "with" was previously considered to be not worth the potential breakage.

Unfortunately, even when we remove the "with(values)" from the library, all applications and OEM's using previous releases (both GPL and commercial) will need to upgrade or be patched. Is there any way to preserve compatibility here?

Comment 16

4 years ago
To look at unminified version of the library, see http://cdn.sencha.com/ext/commercial/4.2.1/ext-all-debug.js
(In reply to don from comment #15)
> Unfortunately, even when we remove the "with(values)" from the library, all
> applications and OEM's using previous releases (both GPL and commercial)
> will need to upgrade or be patched. Is there any way to preserve
> compatibility here?

Thank you for getting back to us on this!

Sadly, there isn't really a way to preserve compatibility and still introduce Array#values(). You're probably aware of the es-discuss conversation about this, but here it is, for completeness' sake:
http://esdiscuss.org/topic/arrayprototypevaluescompatibilityhazard
[updating summary to remove "Firefox 24" -- per bug 875433 comment 11, the regressing patch was backed out and re-landed after Trunk became Firefox 25.  Firefox 24 (currently on Aurora) should be unaffected.]
Summary: TYPO3 compatibility regression in Firefox 24 → TYPO3 compatibility regression in Nightly
(In reply to Daniel Holbert [:dholbert] from comment #18)
> [updating summary to remove "Firefox 24" -- per bug 875433 comment 11, the
> regressing patch was backed out and re-landed after Trunk became Firefox 25.
> Firefox 24 (currently on Aurora) should be unaffected.]

Updating tracking flags to reflect this.
status-firefox24: affected → unaffected
status-firefox25: --- → affected
tracking-firefox24: + → ---
tracking-firefox25: --- → ?

Updated

4 years ago
tracking-firefox25: ? → +
Naveed - can you help with assignment here? We're halfway through the beta cycle, so if this is still important for release we need to fix soon (or backout the regressing bug again).
Assignee: general → nihsanullah
If anyone can reproduce, reopen this bug. I think it's a DUP and it's been fixed for weeks.

See also bug 881782, comments 29 and 30.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 892225

Updated

4 years ago
tracking-firefox25: + → ---
This works for me now in the latest Release, Beta, Aurora, and Nightly.
Status: RESOLVED → VERIFIED
status-firefox25: affected → fixed
You need to log in before you can comment on or make changes to this bug.