Particle-based WebGL simulation is broken in Firefox 17

RESOLVED WORKSFORME

Status

()

Core
Canvas: WebGL
RESOLVED WORKSFORME
5 years ago
4 years ago

People

(Reporter: Loic, Unassigned)

Tracking

({regression})

17 Branch
x86_64
Windows 7
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox17-, firefox18-, firefox25 unaffected, firefox26+ wontfix, firefox27 wontfix, firefox28 wontfix, firefox-esr24 unaffected)

Details

(Whiteboard: webgl-site)

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
Created attachment 668892 [details]
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
(Reporter)

Updated

5 years ago
tracking-firefox17: --- → ?
tracking-firefox18: --- → ?
Keywords: regression, regressionwindow-wanted

Comment 1

5 years ago
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

Updated

5 years ago
Blocks: 774755
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.
(Reporter)

Updated

5 years ago
Keywords: regressionwindow-wanted

Comment 3

5 years ago
(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.
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).

Updated

5 years ago
tracking-firefox17: ? → -
tracking-firefox18: ? → -

Comment 5

5 years ago
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'
This seems really broken on Linux.
Whiteboard: webgl-site
(Reporter)

Comment 7

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

Comment 8

4 years ago
The demo is completely broken in Firefox26beta and later.

Comment 9

4 years ago
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
Blocks: 883478
tracking-firefox26: --- → ?
tracking-firefox27: --- → ?
tracking-firefox28: --- → ?

Updated

4 years ago
status-firefox25: --- → unaffected
status-firefox26: --- → affected
status-firefox27: --- → affected
status-firefox28: --- → affected

Comment 10

4 years ago
The original problem was a bug of ANGLE http://code.google.com/p/angleproject/issues/detail?id=394
(Reporter)

Comment 11

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

Comment 12

4 years ago
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?
Benoit - can you answer the question in comment 12?
Flags: needinfo?(bjacob)
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.
Flags: needinfo?(bjacob)
Alright, well it repros for me on trunk with Linux and the NV binary driver.
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?
Assignee: nobody → bjacob
tracking-firefox26: ? → +
tracking-firefox27: ? → +
tracking-firefox28: ? → +
Please check with :milan if you need an assignee here, I already have stuff on my plate.
Assignee: bjacob → nobody
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
We're getting close to shipping FF26 with no update here - is this still reproducing and is this due to bug 883478?
Flags: needinfo?(jgilbert)
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.
status-firefox26: affected → wontfix
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.
Flags: needinfo?(jgilbert)
(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 ?
status-firefox-esr24: --- → unaffected
(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.
I also don't think we should track this anymore.
tracking-firefox27: + → ---
tracking-firefox28: + → ---

Comment 25

4 years ago
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?
(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.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
status-firefox27: affected → wontfix
status-firefox28: affected → wontfix
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.