798919 - Particle-based WebGL simulation is broken in Firefox 17

Status: RESOLVED WORKSFORME

(Core :: Graphics: CanvasWebGL, defect)

Description

[Loic]

Attachment: Screenshot FF15 vs FF17/18 on Win 7

STR:
Open http://wildabc.github.com/WebGL/FLIP.html then click on the "Start" button.

Result:
The sand should flow from its free right surface but that's not the case, it flows from top to bottom, which is completely broken.

m-c
good=2012-07-25
bad=2012-07-26
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ef20925bc2a5&tochange=20db7c6d82cc

Suspected bug: 
Bug 774755 - Update ANGLE to r1242

Comment 1

[Alice0775 White]

Regression window:
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/94e2e8ea1d11
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120725080955
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/ae6b9545a0f4
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120725092655
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=94e2e8ea1d11&tochange=ae6b9545a0f4

Comment 2

[Benoit Jacob [:bjacob] (mostly away)]

Thanks for this. That's now 2 regressions in ANGLE r1242. Will have to report to ANGLE devs and see if a newer ANGLE revision fixes that.

Comment 3

[Alex Keybl [:akeybl]]

(In reply to Benoit Jacob [:bjacob] from comment #2)
> Thanks for this. That's now 2 regressions in ANGLE r1242. Will have to
> report to ANGLE devs and see if a newer ANGLE revision fixes that.

From your perspective, would this bug warrant backing out part or all of r1242? Basically, is this in any significant use? If not, we likely won't track for release.

Comment 4

[Benoit Jacob [:bjacob] (mostly away)]

No, this doesn't warrant reverting to the now-old version of ANGLE that we were using prior to the r1242 upgrade (I believe that was r1042). That upgrade brought very significant benefits, including in terms of security (new preprocessor) and image quality (anisotropic filtering). No need to track for release -- so far it seems that we can live with the regression, as only a few pages seem affected.

But it would be very interesting to understand more about the regression, and if it's a ANGLE bug, get it fixed (the alternative would be if it's a bug in these pages that got expose by a stricter ANGLE).

Comment 5

[wildabc]

I am the author of that page.The shader id="fs-prolong" cannot be compiled.
Error: WebGL: linkProgram failed, with this log:
(49,7): error X3003: redefinition of 's1'

Comment 6

[Kelsey Gilbert [:jgilbert]]

This seems really broken on Linux.

Comment 7

[Loic]

It's fine on Win 7 with FF25, maybe the demo author has fixed the issue on his side.

Comment 8

[Alice0775 White]

The demo is completely broken in Firefox26beta and later.

Comment 9

[Alice0775 White]

Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/2be3551a5d80
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 ID:20130906171346
Bad  Broken again:
http://hg.mozilla.org/integration/mozilla-inbound/rev/356866ae2f68
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 ID:20130906172546
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=2be3551a5d80&tochange=356866ae2f68

Regressed by:
356866ae2f68	Jeff Gilbert — Bug 883478 - Update ANGLE to pull from 13-08-02. r=upstream,bjacob,bas

Comment 10

[wildabc]

The original problem was a bug of ANGLE http://code.google.com/p/angleproject/issues/detail?id=394

Comment 11

[Loic]

So it has been fixed in ANGLE r1835 and it's broken again?

Comment 12

[alco]

As stated also in Comment 6 , that's not a win-only problem. Completely broken on linux, for me too.
Is this going to affect a large number of webpages, or only a few as stated in Comment 4?

Comment 13

[Lukas Blakk [:lsblakk] use ?needinfo]

Benoit - can you answer the question in comment 12?

Comment 14

[Benoit Jacob [:bjacob] (mostly away)]

This bug is WORKSFORME here on Linux, Ubuntu 12.04 LTS, x86-64, Intel driver, Nightly 28.0a1.

I had no idea how many webpages it would have affected, because I don't know what the issue was. But anyway, if this was caused by some ANGLE upgrade, since there have been more ANGLE upgrades since, this couldn't be fixed just by backing out something at this point. One would have to reproduce and debug this issue to understand exactly what is going on.

But again, this is WORKSFORME here.

Comment 15

[Kelsey Gilbert [:jgilbert]]

Alright, well it repros for me on trunk with Linux and the NV binary driver.

Comment 16

[Alex Keybl [:akeybl]]

We probably should have opened up a completely new bug, but let's keep on in this one for now.

bjacob, can you work with jgilbert since this is seemingly a new FF26 regression we'd like to avoid shipping?

Comment 17

[Benoit Jacob [:bjacob] (mostly away)]

Please check with :milan if you need an assignee here, I already have stuff on my plate.

Comment 18

[Milan Sreckovic [:milan] (needinfo for best results)]

It's hard to rush anything about ANGLE, but that's not news to anybody.  As for the number of pages, seems either very large (anybody using &&) or some subset of that, as it wasn't clear from the comments in the bug as to what conditions lead to this aggressive optimization.  Let's see if there is a fix beyond the "get new angle" and go from there.
Jeff, since you can reproduce it, can you verify that it was Bug 883478 - Update ANGLE to pull from 13-08-02. r=upstream,bjacob,bas that regressed it?  I'll try to reproduce this myself as well

Comment 19

[Lukas Blakk [:lsblakk] use ?needinfo]

We're getting close to shipping FF26 with no update here - is this still reproducing and is this due to bug 883478?

Comment 20

[Lukas Blakk [:lsblakk] use ?needinfo]

It's too late for speculative changes to the FF26 beta so we're going to have to wontfix this. We'll find out if this affects a lot of pages or not when it ships and we start getting user feedback. Hoping that since it's not being reported in large numbers by windows users on beta that we're not going to experience that.

Comment 21

[Kelsey Gilbert [:jgilbert]]

FWIW, Chrome Canary has the same bug. It's possible this is a bug in the script, not the implementation, but it's also possible Chrome has the same bad pull as us.

Comment 22

[bhavana bajaj [:bajaj]]

(In reply to Jeff Gilbert [:jgilbert] from comment #21)
> FWIW, Chrome Canary has the same bug. It's possible this is a bug in the
> script, not the implementation, but it's also possible Chrome has the same
> bad pull as us.

Jeff, anything we can do to confirm this ? What's the fate of this bug in case it is in our code ? Is this something that will go in your backlog as future project work for WebGL and something that is not appropriate for release tracking at this point ?

Comment 23

[Kelsey Gilbert [:jgilbert]]

(In reply to bhavana bajaj [:bajaj] from comment #22)
> (In reply to Jeff Gilbert [:jgilbert] from comment #21)
> > FWIW, Chrome Canary has the same bug. It's possible this is a bug in the
> > script, not the implementation, but it's also possible Chrome has the same
> > bad pull as us.
> 
> Jeff, anything we can do to confirm this ? What's the fate of this bug in
> case it is in our code ? Is this something that will go in your backlog as
> future project work for WebGL and something that is not appropriate for
> release tracking at this point ?

Since this performs similarly in 26+ under ANGLE as under native GL, I'm going to assume that this page is relying on behavior not guaranteed by the GL spec. With more time, I might be able to figure out what exactly changed that causes it to no longer work, but I'm inclined to believe that it's current "broken" state is not an issue with either GL or ANGLE's implementations. Rather, I suspect that this page uses GL incorrectly.

I heavily encourage the author to assume the implementation is correct, and investigate what exactly is causing this bad behavior. I'm not going to close this bug yet, but I'll state that working on this bug is now very low priority for us.

Comment 24

[Kelsey Gilbert [:jgilbert]]

I also don't think we should track this anymore.

Comment 25

[wildabc]

Recently I have time to cope with this problem and I have fixed it. It seems that the behavior of Firefox changed when rendering to texture.
I think this issue should have be closed when the original bug was fixed by ANGLE. I am sorry I did not report it immediately.
Can you tell me where to find the changelog of WebGL behavior of Firefox?

Comment 26

[Kelsey Gilbert [:jgilbert]]

(In reply to wildabc from comment #25)
> Recently I have time to cope with this problem and I have fixed it. It seems
> that the behavior of Firefox changed when rendering to texture.
> I think this issue should have be closed when the original bug was fixed by
> ANGLE. I am sorry I did not report it immediately.
> Can you tell me where to find the changelog of WebGL behavior of Firefox?

The only thing we have is browsing bugzilla's WebGL module for FIXED bugs.

Marking WFM. Please reopen if you suspect this is actually a bug.