1036029 - With lightweight theme applied, a strip at the bottom of the location bar is frequently blanked out, making text harder to read

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect)

Description

[Daniel Holbert [:dholbert]]

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.

Comment 1

[Daniel Holbert [:dholbert]]

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

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screencast

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/

Comment 3

[:Gijs (he/him)]

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?

Comment 4

[Daniel Holbert [:dholbert]]

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

Comment 5

[Daniel Holbert [:dholbert]]

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

Comment 6

[Daniel Holbert [:dholbert]]

(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.)

Comment 7

[:Gijs (he/him)]

(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...). :-\

Comment 8

[Daniel Holbert [:dholbert]]

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.

Comment 9

[Daniel Holbert [:dholbert]]

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)

Comment 10

[Daniel Holbert [:dholbert]]

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.

Comment 11

[Daniel Holbert [:dholbert]]

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

Comment 12

[Nicolas Silva [:nical]]

(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?

Comment 13

[Nicolas Silva [:nical]]

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).

Comment 14

[Nicolas Silva [:nical]]

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.

Comment 15

[Nicolas Silva [:nical]]

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.

Comment 16

[Jeff Muizelaar [:jrmuizel]]

(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.

Comment 17

[Nicolas Silva [:nical]]

(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.

Comment 18

[Nicolas Silva [:nical]]

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