Closed Bug 1255747 Opened 8 years ago Closed 8 years ago

First Run blue indicator is not displayed properly after reloading the page

Categories

(Core :: Widget: Gtk, defect)

46 Branch
x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1225044
Tracking Status
firefox45 --- unaffected
firefox46 --- unaffected
firefox47 + wontfix
firefox48 --- wontfix

People

(Reporter: adalucinet, Unassigned)

References

()

Details

(Keywords: regression, Whiteboard: [gfx-noted])

Attachments

(1 file)

Attached image Screenshot (deleted) —
[Affected versions]: latest Developer Edition 47.0a2 and Nightly 48.0a1(both from 2016-03-10), e10s on/off

[Affected platforms]: Ubuntu 12.04 64-bit

[Steps to reproduce]:
1. Launch Developer Edition.
2. Wait for the first run page to load.
3. Click Next buttons via the first run panel.
4. Refresh the page and repeat step 3.

[Expected result]: The blue indicator is displayed properly.

[Actual result]: The blue indicator is not displayed properly (screenshot attached). 

[Manually performed regression range]:
Last good: 2016-02-26
First bad: 2016-02-27
Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=918df3a0bc1c&tochange=5e0140b6d118

[Additional notes]:
1. Screenshot attached.
2. On Ubuntu 14.04 64-bit, a square is displayed instead of the blue indicator - Screenshot https://goo.gl/UMuk9O - which is also reproducible with the last good nightly build (from 2016-02-26) mentioned above; I'm sure I saw a similar report, but I'm unable to find it for now.
Can you narrow this regression range down further with inbound / fx-team builds?
Flags: needinfo?(alexandra.lucinet)
[Tracking Requested - why for this release]: user-facing regression affecting the First Run tour.
(In reply to :Gijs Kruitbosch from comment #1)
> Can you narrow this regression range down further with inbound / fx-team
> builds?

Sure! - narrowed the range to this pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d78875efa55acb8f8849336e264bee955ce6a460&tochange=bd59893f50b8c7107ab6c07cb2337c1d5cc09184

Regressed by bug 1249813 - nsShmImage doesn't reuse its image when different regions are passed to it

Lee, any ideas?
Flags: needinfo?(alexandra.lucinet) → needinfo?(lsalzman)
Keywords: regression
Flags: needinfo?(lsalzman)
Whiteboard: [gfx-noted]
Tracked since this is a new regression in Fx47.
I am looking into this a bit more, but I do not think the regression range provided here is reliable, as I can pretty much back out all my changes, re-enable XRender, use the OpenGL compositor, and I can still reproduce the issue, even though my changes don't use or touch those render paths.

I was able to reproduce this in a 46.0b2 build using GTK3 as well, which was before my changes.

You have to be persistent about reloading, as the behavior is not deterministic. Sometimes the problem happens immediately, or sometimes it takes tens of reloads. Can you see if you can get it to reproduce on any earlier GTK3 builds?
Flags: needinfo?(alexandra.lucinet)
karlt was able to reproduce this on 45.0b5, though it does not seem to happen on GTK2 builds.

So the evidence points more to some sort of race in either the GTK3 theme code or the gtk nsWindow code.
(In reply to Lee Salzman [:lsalzman] from comment #5)
> I am looking into this a bit more, but I do not think the regression range
> provided here is reliable, as I can pretty much back out all my changes,
> re-enable XRender, use the OpenGL compositor, and I can still reproduce the
> issue, even though my changes don't use or touch those render paths.

Maybe we are missing something here? The regression range was performed 2 times, both with the same output - your bug. 

> I was able to reproduce this in a 46.0b2 build using GTK3 as well, which was
> before my changes.

I'm not able to reproduce with 46.0a2 (2016-02-24), which has GTK3 as far as I can tell - in about:buildconfig page I saw that there is '--enable-default-toolkit=cairo-gtk3' entry under Configure arguments area. Not reproducible for me neither with 45.0b5 (Build ID: 20160211221018).

> You have to be persistent about reloading, as the behavior is not
> deterministic. Sometimes the problem happens immediately, or sometimes it
> takes tens of reloads. Can you see if you can get it to reproduce on any
> earlier GTK3 builds?

On the bad builds, it happens right after the first reload. Please let me know if I can help more!
Flags: needinfo?(alexandra.lucinet)
I would like you to try toggling the following prefs to these values, both individually, and all at once, and report back the results of each:
gfx.xrender.enabled: true
layers.use-image-offscreen-surfaces: false
layers.acceleration.force-enabled: true

I would also need to know what version of GTK3 you have installed.

Finally, if you could paste the Graphics section of about:support
Flags: needinfo?(alexandra.lucinet)
I can reproduce this with the Nightly of 2015-07-24, the first with gtk3.
Blocks: 1186229
Blocks: 1186003
No longer blocks: 1186229
(In reply to Lee Salzman [:lsalzman] from comment #8)
> I would like you to try toggling the following prefs to these values, both
> individually:
> gfx.xrender.enabled: true
- not reproducible
> layers.use-image-offscreen-surfaces: false
- reproducible
> layers.acceleration.force-enabled: true
- reproducible
And with all at once, it's not reproducible.

> I would also need to know what version of GTK3 you have installed.
libgtk-3-0     3.4.2-0ubuntu0 GTK+ graphical user interface library

> Finally, if you could paste the Graphics section of about:support
Graphics
Adapter Description	X.Org -- Gallium 0.4 on AMD RS780
Asynchronous Pan/Zoom	wheel input enabled
Device ID	Gallium 0.4 on AMD RS780
Driver Version	3.0 Mesa 9.1.7
GPU Accelerated Windows	0/1 Basic (OMTC)
Supports Hardware H264 Decoding	No
Vendor ID	X.Org
WebGL Renderer	X.Org -- Gallium 0.4 on AMD RS780
windowLayerManagerRemote	true
AzureCanvasAccelerated	0
AzureCanvasBackend	cairo
AzureContentBackend	cairo
AzureFallbackCanvasBackend	none
CairoUseXRender	1
Flags: needinfo?(alexandra.lucinet)
Component: Tours → Widget: Gtk
Product: Firefox → Core
This looks pretty bad, but also polishy. Karl?
Flags: needinfo?(karlt)
Thanks for the report.  There's analysis in bug 1225044, so let's track there.
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(karlt)
Resolution: --- → DUPLICATE
This is a visual regression that we should fix soon (48/49). However, evaluating this in 47 RC week, it does not seem like a release blocker though a bad UI rendering issue (looking at the screen snapshot).
This was at least in 46; see bug 1225044 comment 21.
Version: Trunk → 46 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: