NASA WorldWind virtual globe not displayed in FireFox 63

RESOLVED FIXED in Firefox 64

Status

()

defect
--
major
RESOLVED FIXED
9 months ago
8 months ago

People

(Reporter: bruce, Assigned: evilpie)

Tracking

({regression})

63 Branch
mozilla65
x86_64
Windows 10
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +
qe-verify -

Firefox Tracking Flags

(firefox-esr60 unaffected, firefox63+ wontfix, firefox64+ fixed, firefox65+ fixed)

Details

Attachments

(2 attachments)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/17.17134

Steps to reproduce:

I am attempting to interact with a 3D virtual globe of the earth using a NASA Web WorldWind based web app (WebGL-based). This worked in Firefox 62 and works in the other major browsers.
  
Here are some URLs that exhibit the issue:
1. Open the Explorer web app (https://worldwind.earth/explorer/).
2. Open any of the NASA WebWorldWind SDK examples (https://worldwind.arc.nasa.gov/web/examples/)

Additional info: https://github.com/NASAWorldWind/WebWorldWind/issues/790




Actual results:

The HTML canvas does not display the WebGL-based globe.  Instead, a blank canvas is displayed (no globe) and the globe's screen annotations (text, symbols) are all displayed in the upper right-hand corner (stretched, distorted and on top of each other)


Expected results:

An interactive 3D view of the earth should have been displayed in the center of the canvas, with screen annotations (text, symbols) anchored in various positions around the periphery of the canvas.
Severity: normal → major
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64
There are 2 regression ranges, the first one is from working to not working with mostly a black screen and high CPU utilization 

 4:15.17 INFO: No more inbound revisions, bisection finished.
 4:15.17 INFO: Last good revision: 5cad39f6116b0f2ab7df5ac0bcb518775f03af97
 4:15.17 INFO: First bad revision: 846e6b6678b6c6804d3d86fd7f86c6ca4d9a477d
 4:15.17 INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=5cad39f6116b0f2ab7df5ac0bcb518775f03af97&tochange=846e6b6678b6c6804d3d86fd7f86c6ca4d9a477d

-=> Bug 1413794


the second one is from mostly black screen to all annotations into the top right corner

 3:51.41 INFO: Last good revision: 96504aefa81f2bd3a0c7daaa17043a20db48e59b
 3:51.41 INFO: First bad revision: 8e4a266f45fd08a3a6bc0d5153ba37abc6cbdacd
 3:51.41 INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=96504aefa81f2bd3a0c7daaa17043a20db48e59b&tochange=8e4a266f45fd08a3a6bc0d5153ba37abc6cbdacd

-=> Bug 1473523 

It's of course possible that the second regression range is the fix for the first one and a different regression occurred in the meantime.
Blocks: 1413794, 1473523
Status: UNCONFIRMED → NEW
Component: Untriaged → JavaScript Engine
Ever confirmed: true
Flags: needinfo?(evilpies)
Product: Firefox → Core
Okay, this seems to be caused by code like this: https://github.com/Anson-Zhao/FAMEWS/blob/7810d6f3676aca8aa58884b1a093c65b58e1c809/src/geom/Matrix.js#L338

Reduced example:

function Vec3(x, y, z) {
  this[0] = x;
  this[1] = y;
  this[2] = z;
}

Vec3.prototype = new Float32Array(3);

Vec3.prototype.set = function(x, y, z) {
  this[0] = x;
  this[1] = y;
  this[2] = z;
}

var vec = new Vec3(1, 2, 3);
console.log(vec);
vec.set(5, 6, 7);
console.log(vec);

In Firefox this modifies the Float32Array on the prototype. In Chrome and presumably Edge as well, this defines three new elements 0,1,2 on the |vec| instance. Presumably this change is just not webcompatible? We will probably need to change the ECMAScript spec as well.
Flags: needinfo?(evilpies)
Assignee: nobody → evilpies
Keywords: regression
Keywords: regression
Pushed by evilpies@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/79eaa3fb6632
Revert TypedArray [[Set]] to previous behavior if not receiver. r=jorendorff
https://hg.mozilla.org/mozilla-central/rev/79eaa3fb6632
Status: NEW → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
Duplicate of this bug: 1503489
We probably want to uplift this.
Please nominate this for Beta approval when you get a chance.
Flags: needinfo?(evilpies)
Flags: in-testsuite+
Keywords: regression
Comment on attachment 9020905 [details]
Bug 1502889 - Revert TypedArray [[Set]] to previous behavior if not receiver. r?jorendorff,anba

[Beta/Release Uplift Approval Request]

Feature/Bug causing the regression: Bug 1413794

User impact if declined: Web sites that uses typed array might break, for example https://worldwind.earth/explorer/

Is this code covered by automated tests?: Yes

Has the fix been verified in Nightly?: Yes

Needs manual test from QE?: No

If yes, steps to reproduce: 

List of other uplifts needed: None

Risk to taking this patch: Medium

Why is the change risky/not risky? (and alternatives if risky): This mostly just reverts the code, but this quite complicated stuff.

String changes made/needed:
Flags: needinfo?(evilpies)
Attachment #9020905 - Flags: approval-mozilla-beta?
Comment on attachment 9020905 [details]
Bug 1502889 - Revert TypedArray [[Set]] to previous behavior if not receiver. r?jorendorff,anba

[Triage Comment]
Fixes possible bustage of websites using typed arrays. Approved for 64.0b6. Thanks for including new tests with this patch.
Attachment #9020905 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Setting qe- per commment#9
Flags: qe-verify-
I don't think this is going to land in 63 at this point.
You need to log in before you can comment on or make changes to this bug.