Starting today, I'm noticing a strip at the bottom of the location bar ( aka url bar / awesome bar) is consistently blank. When I focus the bar, it gets repainted, but when I open a new tab, or switch tabs, it ends up blank again. I can reproduce it reliably in a fresh profile, after opening Tools|Addons (which opens a new tab) and then switching to another tab and back to the addons tab.

I'm using up-to-date Nightly: 33.0a1 (2014-07-08) Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0 Ubuntu 14.04

here's a screencast, with a fresh profile, which just has this lightweight theme applied: https://addons.mozilla.org/en-US/firefox/addon/p%C3%A1fr%C3%A1ny-lev%C3%A9l-04/

I'm very much not convinced this is a Fx Theme rather than a graphics issue... can you get a specific regression window with mozregression? And can you reproduce with hardware acceleration turned off?

mozregression indicates that it is indeed a regression in today's build. It narrows it to this range (w/ assistance from inbound tinderbox builds): Last good revision: 81691a55e60f First bad revision: d1fc91b11561 Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=81691a55e60f&tochange=d1fc91b11561

(and unchecking "use hardware acceleration where available" & restarting has no effect.)

(Also: I can reproduce this in a fresh profile [w/ lightweight theme added] on both of my work linux machines - a dell desktop & a Thinkpad, both running Ubuntu 14.04.)

(In reply to Daniel Holbert [:dholbert] from comment #4) > mozregression indicates that it is indeed a regression in today's build. > > It narrows it to this range (w/ assistance from inbound tinderbox builds): > Last good revision: 81691a55e60f > First bad revision: d1fc91b11561 > Pushlog: > https://hg.mozilla.org/integration/mozilla-inbound/ > pushloghtml?fromchange=81691a55e60f&tochange=d1fc91b11561 wat. That is still a pretty huge regression range (and also includes a bunch of fx-team changes, but none that look particularly suspect here...). :-\

Yeah. I'm not sure why mozregression gave up at that point. The mozilla-central regression range is... http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1dc6b294800d&tochange=c45f6e6d6005 ...which is only slightly larger than the mozilla-inbound range. (The merge history makes it a bit confusing to reason about the intersection of those ranges; it looks like the oldest changeset-in-common is ceff7d54080f, and the newest changeset-in-common is 75022b09e69c.) Anyway, I'm kicking off a few targeted builds to see if I can narrow it down further. Bug 530985 seems like one possible candidate (changing how we calculate bounding rects), at first glance.

Tightened regression range, from targeted local builds: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b2fd5a214d2a&tochange=c6adaead7adf (In reply to Daniel Holbert [:dholbert] from comment #8) > Bug 530985 seems like one possible candidate (changing how we > calculate bounding rects), at first glance. (never mind about that - it's not in this tightened range)

Further-tightened range: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b2fd5a214d2a&tochange=51895ae51261 In that range, Bug 1034593 looks most suspicious, and indeed, reverting its cset seems to fix this bug. Marking as a regression from that bug.

nical, this seems to be a regression from a checkin of yours yesterday. Could you take a look?

(In reply to Daniel Holbert [:dholbert] from comment #11) > nical, this seems to be a regression from a checkin of yours yesterday. > Could you take a look?

I think I found a way to fix the problem but I haven't yet fully understood why it fixes it. Patch coming soon (when I figure it out properly).

I am not certain but I think that we can't use the target surface extents to intersect with the clip extents. while the target extents have the right width/height it doesn't seem to contain the appropriate x and y offsets, that are not passed to _cairo_clip_path_get_surface. looking at some code that uses _cairo_clip_get_surface in cairo-image-surface.c, it looks like there is sometimes a non-null offset which is applied when doing the composition operations. When this happens, the intersection computed in _cairo_clip_path_get_surface is incorrect.

Jeff, is what i am saying in comment 14 making sense? If so i'll backout the patch in bug 1034593 and look for a different way to get google streetview to work.

(In reply to Nicolas Silva [:nical] from comment #15) > Jeff, is what i am saying in comment 14 making sense? If you subtract or add the device offset I think you might be able to make these extents work out.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #16) > (In reply to Nicolas Silva [:nical] from comment #15) > > Jeff, is what i am saying in comment 14 making sense? > > If you subtract or add the device offset I think you might be able to make > these extents work out. Unfortunately the target's device offset is always equal to zero as far as I can tell.

This was fixed by backing out the patch bug 1034593 that caused the regression.