[Tracking Requested - why for this release]: regression, looks very broken STR: 1. Go to https://paulbakaus.com/2015/10/27/amplifying-the-web/ 2. Move your mouse over the first image in the "Stuff I like" sidebar. 3. Wait for the image to grow, and a little longer. Now the image disappears. If you move the mouse away from it, suddenly all images in the sidebar disappear. mozregression gave me https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=646c99efe919cbd123437448deb5dce8a3429720&tochange=69871c00379ba9a262f3a8cc2072da4a0892b2ee , so this is a regression from bug 1180326. That means it's on beta, but not on release yet.

Tracking for 43 since this is a regression. We are releasing 42 so this is mostly likely a wontfix for 42.

I don't think it is critical enough to do a dot release.

Sometimes the region we want to draw/validate can be bigger than the visible region (we pad out by 1px to prevent resampling artifacts), so we need to make sure we use the former for deciding what size buffer to allocate. We were using the visible region, getting a dirty rect starting at -1 and then getting a GL error when trying to upload using those coordinates.

I suspect this is behind some of the common crashes (e.g., bug 1176404), so doing uplifts all the way would be awesome.

(In reply to Matt Woodrow (:mattwoodrow) from comment #3) > ... > We were using the visible region, getting a dirty rect starting at -1 and > then getting a GL error when trying to upload using those coordinates. Do we ever have borders on our textures? If not, should we be catching index < 0?

(In reply to Milan Sreckovic [:milan] from comment #6) > (In reply to Matt Woodrow (:mattwoodrow) from comment #3) > > ... > > We were using the visible region, getting a dirty rect starting at -1 and > > then getting a GL error when trying to upload using those coordinates. > > Do we ever have borders on our textures? If not, should we be catching > index < 0? We don't, no. Our GL error mode catches this, though I guess we could have a more permanent error as well.

Matt, want to request uplift? Is there a good way to verify the fix on nightly?

I can't recall now what related symptom I was seeing, but it did go away when I applied this patch, so as vague as that sounds :), I think I'm going to claim this fixes the problem.

Comment on attachment 8686897 [details] [diff] [review] Use the valid region for determing buffer size Approval Request Comment [Feature/regressing bug #]: Bug 1180326. [User impact if declined]: Dynamic webpages fail to update sometimes [Describe test coverage new/current, TreeHerder]: Tested manually. [Risks and why]: Very low risk, just changes the bufffer size we allocate. [String/UUID change made/needed]: None.

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #10) > Matt, want to request uplift? Is there a good way to verify the fix on > nightly? The STR in this bug, and in bug 1223003 should be good for verification.

Comment on attachment 8686897 [details] [diff] [review] Use the valid region for determing buffer size Fix for recent regression, looks good on Nightly. OK to uplift to aurora and beta.

Verified fixed FF 44.0a2 (2015-11-22), 45.0a1 (2015-11-22) OS X 10.11. It seems like the fix didn't make it to 43b5. Will re-check in beta 6.

Verified fixed FF 43b8 OS X 10.11.