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
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
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.
(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).
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.
It's fine on Win 7 with FF25, maybe the demo author has fixed the issue on his side.
The demo is completely broken in Firefox26beta and later.
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
The original problem was a bug of ANGLE http://code.google.com/p/angleproject/issues/detail?id=394
So it has been fixed in ANGLE r1835 and it's broken again?
Benoit - can you answer the question in comment 12?
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.
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?
Please check with :milan if you need an assignee here, I already have stuff on my plate.
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?
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.
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.
(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 ?
(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.
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.