1005501 - Solid coloured rectangles/bars/boxes instead of text in address/location bar

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[david]

Attachment: Screenshot - 030514 - 17:55:35.png

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140428194004

Steps to reproduce:

1. Wipe hard disk on old "MaxData" laptop clean
2. Install Xubuntu 14.04 on laptop
3. Log in and open Firefox


Actual results:

Words in the location/address bar are sometimes replaced by solid bars or rectangles in the same colour as the text that should be there, i.e. grey, black and green boxes in the address bar. See attached screen shot.

Sometimes the text does show, but turns to the boxes if you go to another tab and come back to the first one.


Expected results:

The text of the URL should appear and be present all the time.

Comment 1

[david]

Attachment: Firefox config info

Comment 2

[david]

This seems similar to
https://bugzilla.mozilla.org/show_bug.cgi?id=654570
but I think it is distinct, as this only affects the address bar.

Comment 3

[david]

I should add that I've tried this in safe mode and with hardware accelleration turned off from within Firefox preferences.

Comment 4

[photon89]

I also experience the same bug since the update to Firefox 29. It might be related to https://bugzilla.mozilla.org/show_bug.cgi?id=1004888 although the graphical glitch looks different. Are you also using an Intel card?

Comment 6

[david]

Yes, it's an Intel card; here's the information from the firefox troublehooting option:

 "graphics": {
    "numTotalWindows": 1,
    "numAcceleratedWindows": 0,
    "windowLayerManagerType": "Basic",
    "windowLayerManagerRemote": false,
    "numAcceleratedWindowsMessage": [
      "blockedGfxCard"
    ],
    "adapterDescription": "Intel Open Source Technology Center -- Mesa DRI Intel(R) 852GM/855GM x86/MMX/SSE2",
    "adapterVendorID": "Intel Open Source Technology Center",
    "adapterDeviceID": "Mesa DRI Intel(R) 852GM/855GM x86/MMX/SSE2",
    "adapterRAM": "",
    "adapterDrivers": "",
    "driverVersion": "1.3 Mesa 10.1.0",
    "driverDate": "",
    "webglRendererMessage": [
      "blockedGfxCard"
    ],
    "info": {
      "AzureCanvasBackend": "cairo",
      "AzureSkiaAccelerated": 0,
      "AzureFallbackCanvasBackend": "none",
      "AzureContentBackend": "cairo"
    }
  },

Comment 7

[Thomi Schmid]

Same here: Intel "Centrino" graphics card... used to have problems with KMS years ago, which since then have gone away. Laptop resp. graphics card worked fine with Firefox 28 (in Xubuntu 14.04 and openSuSE 13.1).


Extensions:
-------------

Name: Ubuntu Firefox Modifications
Version: 2.8
Aktiviert: true
ID: [e-mail]

Important modified settings:
-----------------------------------

browser.cache.disk.capacity: 358400
browser.cache.disk.smart_size_cached_value: 358400
browser.cache.disk.smart_size.first_run: false
browser.cache.disk.smart_size.use_old_max: false
browser.places.smartBookmarksVersion: 6
browser.sessionstore.upgradeBackup.latestBuildID: 20140428194004
browser.startup.homepage: http://www.xindel.ch/
browser.startup.homepage_override.buildID: 20140428194004
browser.startup.homepage_override.mstone: 29.0
dom.mozApps.used: true
extensions.lastAppVersion: 29.0
gfx.blacklist.direct2d: 4
gfx.blacklist.layers.direct3d10: 4
gfx.blacklist.layers.direct3d10-1: 4
gfx.blacklist.layers.direct3d9: 4
gfx.blacklist.layers.opengl: 4
gfx.blacklist.stagefright: 4
gfx.blacklist.webgl.angle: 4
gfx.blacklist.webgl.msaa: 4
gfx.blacklist.webgl.opengl: 4
network.cookie.prefsMigrated: true
places.database.lastMaintenance: 1399220800
places.history.expiration.transient_current_max_pages: 12760
plugin.disable_full_page_plugin_for_types: application/pdf
plugins.notifyMissingFlash: false
privacy.sanitize.migrateFx3Prefs: true
storage.vacuum.last.index: 1
storage.vacuum.last.places.sqlite: 1399134750

Grafik
------

Geräte-ID: Mesa DRI Intel(R) 852GM/855GM x86/MMX/SSE2
GPU-beschleunigte Fenster: 0/1 Basic Wurde auf Grund Ihrer Grafikkarte blockiert, da ungelöste
    Treiberprobleme bestehen ("blocked due to your graphics card having unresolved driver problems").
Karten-Beschreibung: Intel Open Source Technology Center -- Mesa DRI Intel(R) 852GM/855GM x86/MMX/SSE2
Treiber-Version: 1.3 Mesa 10.1.0
Vendor-ID: Intel Open Source Technology Center
WebGL-Renderer: Wurde auf Grund Ihrer Grafikkarte blockiert, da ungelöste Treiberprobleme bestehen.
   ("blocked due to your graphics card having unresolved driver problems")
windowLayerManagerRemote: false
AzureCanvasBackend: cairo
AzureContentBackend: cairo
AzureFallbackCanvasBackend: none
AzureSkiaAccelerated: 0

Comment 8

[david]

Following the suggestion at https://bugzilla.mozilla.org/show_bug.cgi?id=1004888  I've just tried putting the following in /etc/X11/xorg.conf

=======

Section "Device"
        Identifier "Configured Video Device"
        Option "NoAccel" "true"
EndSection

Section "Monitor"
        Identifier "Configured Monitor"
EndSection

Section "Screen"
        Identifier "Default Screen"
        Monitor "Configured Monitor"
        Device "Configured Video Device"
EndSection

======

This seems to cure the problem, though I think getting rid of acceleration is making embedded video (BBC Iplayer) a bit slow.

Comment 9

[photon89]

Nice, actually, I'm running an IBM Thinkpad X40 with exactly the same card (and also Xubuntu 14.04). I guess, this bug report gives a good statistics on the number of 855GM users amongst Firefox users. :)

Anyway, I strongly suppose that this is the same bug as https://bugzilla.mozilla.org/show_bug.cgi?id=654570 since, as in the case of its reporter, the problem is introduced in beta8. If anybody who understands the naming of the nightlies cares to test some nightlies, we can get more confidence, but I think, the fact that the bugs are identical is quite probable already.

Comment 10

[photon89]

Sorry, I meant to write https://bugzilla.mozilla.org/show_bug.cgi?id=1004888 !

Comment 11

[Götz]

Instead of turning the acceleration off, try using uxa as acceleration method (sna beeing the default).

   Option  "AccelMethod"  "uxa"

Comment 12

[david]

Yes photon89, it looks like the bugs may be the same. I've not tested any nightlies, but I fancy that fixing #1004888 would probably sort this problem.

Thanks for the suggestion Götz: However, uxa acceleration gives the same bug for me.

Comment 13

[david]

Hmmm.... On second thoughts maybe this bug is distinct from #1004888: Here enabling UXA acceleration doesn't prevent the coloured rectangles instead of text; there enabling UXA works around the problem.

Comment 14

[Götz]

david, maybe updating the intel DDX driver may help. I see Xubunut 14.04 uses xf86-video-intel 2.99.910, I use 2.99.911. 

As suggested by Gijs in bug 1004888, try mozregression ( https://harthur.wordpress.com/2010/09/13/mozregression-update/ ) to narrower the regression range.

Comment 15

[:Gijs (out for now; he/him)]

(In reply to david from comment #3)
> I should add that I've tried this in safe mode and with hardware
> accelleration turned off from within Firefox preferences.

Does this still reproduce with hardware acceleration turned off? And, does your window manager have compositing turned on? For the latter question, if not, does turning it on help?

Comment 16

[photon89]

@Gijs: In my case turning on and off the hardware acceleration in the Firefox preferences shows no effect. Also the bug appears with both Compiz and Xfwm (where under Xfwm with both activated and deactivated compositor). I didn't try playing around with the xorg.conf though.

Comment 17

[david]

(In reply to :Gijs Kruitbosch from comment #15)
> (In reply to david from comment #3)
> > I should add that I've tried this in safe mode and with hardware
> > accelleration turned off from within Firefox preferences.
> 
> Does this still reproduce with hardware acceleration turned off? And, does
> your window manager have compositing turned on? For the latter question, if
> not, does turning it on help?

The bug reproduces with all four permutations of compositing on or off and Firefox hardware acceleration or off. The only thing that I've found to prevent reproduction is turning of hardware acceleration in xorg.conf.

Comment 18

[david]

Running mozregression, as suggested by Götz, leads to the following pushlog:

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=dda301682977&tochange=c89d5f132051

The keyhole patches mentioned in  https://bugzilla.mozilla.org/show_bug.cgi?id=654570 are there. I also noticed that all the good revisions have the old-style back button, whereas all the bad ones have the new-style button.

Comment 19

[david]

I'm trying to build from source via mozregression, but I'm getting the error message 'No TimeStamp implementation on this platform.  Build will not succeed'.  This error occurs in the file mozbuild-trunk/xpcom/ds/moz.build  . I'm giving up for tonight!

Comment 20

[photon89]

I run mozregression today and got the same pushlog as david. Trying to build from source has given no errors so far, but it takes a hell lot of time on this Pentium M 1.2GHz. It runs for some hours already and still builds the first build in the series. Are any precompiled builds of the revisions between the nightlies available? If not, doing the bisection could take a week or two. And another question, is it possible to pause mozregression, shut the laptop down and continue later? Otherwise I need to do all the nightly testing and bisectioning again and again from the very beginning (or cannot switch the laptop off at all).

Comment 21

[:Gijs (out for now; he/him)]

Benoît, can you help move this forward? It seems like a graphics issue to me, possibly specific to particular (Intel?) chip(s), and likely to do with the addition of the "keyhole" back button (using an SVG clip path). Not sure where to go from there. :-)

Comment 22

[Benoit Girard (:BenWa)]

Could this be a problem with XRender bjacob? Otherwise I'd guess it's a cairo bug. If so we can grab a moz2d recording and/or try with skia.

Comment 23

[Benoit Jacob [:bjacob] (mostly away)]

(In reply to Benoit Girard (:BenWa) from comment #22)
> Could this be a problem with XRender bjacob? Otherwise I'd guess it's a
> cairo bug. If so we can grab a moz2d recording and/or try with skia.

The way to tell if this could be XRender related, is to go to about:config, set gfx.xrender.enabled to false, restart the browser, and retry.

Comment 24

[david]

(In reply to Benoit Jacob [:bjacob] from comment #23)
> The way to tell if this could be XRender related, is to go to about:config,
> set gfx.xrender.enabled to false, restart the browser, and retry.

Doing this makes the bug go away. 

One other thing I've noticed is that, when the bug is present, whether the text turns into rectangles depends on the number of pixels the URL occupies horizontally. Short strings render OK, but there is a point at which typing one extra character turns the whole string into the rectangular blocks.

Comment 25

[Thomi Schmid]

>>go to about:config, set gfx.xrender.enabled to false, restart the browser, and retry
> Doing this makes the bug go away.
Same here; addressbar text is now readable again.

Comment 26

[photon89]

I can also confirm that the disabling gfx.xrender solves the issue!

Comment 27

[david]

In a few days, I expect I won't be able to help any more with this issue, as I'm going to be lending the hardware to someone else (as planned), and with gfx.xrender disabled, it's now OK to hand over. However, it looks like there are a couple of others affected by this issue.

Comment 30

[:Gijs (out for now; he/him)]

Milan, seems like quite a few of our Linux users are hitting this, and it makes the browser pretty much completely unusable (not being able to read URLs is... not fun). Do you know if anyone in the Gfx team has time to investigate a fix here?

Comment 31

[Andreas Gal :gal]

Can we bisect this?

Comment 32

[photon89]

If anybody could provide i386 builds of the revisions in question, I'd be glad to help with bisecting. My laptop just takes too long to compile even a single build and I currently have no other i386 system installed.

Comment 33

[:Gijs (out for now; he/him)]

(In reply to Andreas Gal :gal from comment #31)
> Can we bisect this?

Probably not easily, because the underlying GFX bug was revealed by a browser frontend patch (which uses SVG clip paths for the keyhole-style back/fwd button). See also bug 1004888. :-(

Comment 34

[Milan Sreckovic [:milan] (needinfo for best results)]

If this is critical, let's back out that browser frontend patch that caused the regression while we're figuring out how to fix it otherwise.  If that can't be done, then we should push a patch to change the default gfx.xrender.enabled to false.  Who can tell us about the frontend patch you've mentioned?  Is that bug 477948?

Comment 35

[:Gijs (out for now; he/him)]

(In reply to Milan Sreckovic [:milan] from comment #34)
> If this is critical,

That depends how many users this hits. I don't know what xrender is, or if it's specific to certain graphics cards. I do know I've never seen this issue, and nor have various other people, but the number of duplicates is somewhat worrying...

> let's back out that browser frontend patch that caused
> the regression while we're figuring out how to fix it otherwise.  If that
> can't be done, then we should push a patch to change the default
> gfx.xrender.enabled to false.  Who can tell us about the frontend patch
> you've mentioned?  Is that bug 477948?

Yes. Note that this will remove the keyhole again, which we've shipped in 29, ie this would be a highly visible backout. I also don't know if turning off xrender will have other negative side effects and is to be preferred over the backout or not. CC'ing Mike and Dão from bug 477948.

Comment 36

[photon89]

I think that this bug only affects Linux users running an Intel 852GM/855GM/865G card (cf. the duplicates and the comments to this bug). These cards are known to be problematic some years ago, but as of today they are supported quite well. They have been introduced in early 2003, however, so the user number might be limited.

Comment 37

[Milan Sreckovic [:milan] (needinfo for best results)]

Benoit, thoughts on "blacklisting" these cards to not use xrender?

Comment 38

[jdt37b]

For information, old cards Intel 82865G don't posed problem with Xubuntu 12.04 (Precise) and libgl ... mesa version 8. But since Xubuntu 12.10 (Quantal) and libgl .. mesa version 9 and after 10, there are problems (eg.: blank screen with Stellarium). Xubuntu 14.04 (Trusty) add new problems with at least FF 29 and Parole 0.6.1.

As I've read here:
/ Etc/X11/xorg.conf with:
Section "Device"
        Identifier "intel"
        Driver "intel"
        Option "AccelMethod" "uxa"
EndSection

-> With this xorg.conf, FF 29 and Parole are Ok with Trusty  (but not Stellarium because mesa)

Comment 39

[Mike de Boer [:mikedeboer]]

I'm sorry if I completely derail this bug; but I started seeing this using the latest 30.0 beta on OSX...

Yes, on a Mac :(

Comment 40

[:Gijs (out for now; he/him)]

(In reply to Mike de Boer [:mikedeboer] from comment #39)
> I'm sorry if I completely derail this bug; but I started seeing this using
> the latest 30.0 beta on OSX...
> 
> Yes, on a Mac :(

I'm 99% sure this is a different issue. Please file a new bug.

Comment 41

[photon89]

Mike, Gijs: Maybe information on hardware and a screenshot can make things clearer.

Comment 42

[Benoit Jacob [:bjacob] (mostly away)]

(In reply to Milan Sreckovic [:milan] from comment #37)
> Benoit, thoughts on "blacklisting" these cards to not use xrender?

Sure, we can do that. There is no "XRender" blacklisting "feature" yet, so we would need to add one, and blacklist rules based on it would have to be compiled-in, not downloaded blacklist rules.

But we've also been talking for a while about not using XRender anymore. If we could flip that switch now, that would remove the need for adding a "XRender" feature in the blacklisting system.

We've known for a long time that using XRender was increasing our contact surface with drivers in a way that was not necessarily worth it. Our current plan for Linux Layers involves eventually making that move anyway. I'm not current on whether we could consider making it now. Jeff?

Comment 43

[Jeff Muizelaar [:jrmuizel]]

(In reply to Benoit Jacob [:bjacob] from comment #42)
> 
> We've known for a long time that using XRender was increasing our contact
> surface with drivers in a way that was not necessarily worth it. Our current
> plan for Linux Layers involves eventually making that move anyway. I'm not
> current on whether we could consider making it now. Jeff?

Fred is collecting some performance info on different approaches here. Hopefully, we'll know better about what are options are soon.

Comment 44

[Sylvestre Ledru [:Sylvestre]]

Not tracking for 29: we won't do a new release for that bug.
However tracking for 30 & 31 (which I guess are affected too) since hw acceleration + intel gc are quite common.

Comment 45

[Christopher Chavez]

I am running Ubuntu 14.04 with MATE 1.8 on Intel 82865G (good news seems to be no missing package that caused this; bad news is this bug).
In my case, I noticed that clicking around the obscured address can potentially reveal portions of text, but they can re-obscure as well; I wonder if this has anything to do with comment 24. I may add a video to document.

I think the cause, due to it being platform-specific, should be attributed to XRender (and not the keyhole patches), so maybe one of us should go over to bugs.freedesktop.org and report this under xorg:Driver/intel (I think; there seems to be quite a few text corruption bugs, recently and both fixed and unfixed). On the other hand, a fix on XRender's end may not guarantee as quick of a fix for this issue, so a Firefox patch may be necessary, at least temporarily. (My hesitance agreeing with disabling gfx.xrender.enabled application-wide is because I am unaware of the implications, e.g. affecting casual users' experience.) The more important option is a matter of personal choice (Firefox due to popularity, vs. XRender due to potential benefit to larger community), unless there is a specific policy the Mozilla community has in a situation like this (intervention of non-Mozilla-specific 3rd-party bugs).
I would say the same about bug 1004888: additionally, since there is a variation in symptoms there is possibly a different bug to be reported for XRender.

Comment 46

[Lukas Blakk [:lsblakk] use ?needinfo]

We're doing our last FF30 betas next week.  From reading through this bug it seems like we have a few options but disabling gfx.xrender solving the issue (and what is the resulting experience for users when this is done?) makes it look like the most feasible option for FF30 if we were able to promote a Sumo article (and release note) about this to enable users who hit it to return to a usable state. Are there any other viable, low-risk alternatives that could be put into next week's Beta for testing?

Comment 47

[Christopher Chavez]

I have reported a bug over on Freedesktop.org corresponding to this issue (and a separate one for bug 1004888).
https://bugs.freedesktop.org/show_bug.cgi?id=79165

Comment 48

[Christopher Chavez]

I updated my Xorg to the development packages (for Ubuntu, the ppa:xorg-edgers/ppa on launchpad) and the issue is no longer present. Because of the risks involved in upgrading Xorg, though, I'm not sure if the proposed workaround is ruled out.
Interestingly, some users have disabled gfx.xrender.enabled to improve Firefox performance if not introduce glitches as well: http://www.waveguide.se/?article=speed-up-that-sluggish-iceweasel-firefox

Comment 49

[:Gijs (out for now; he/him)]

(In reply to Lukas Blakk [:lsblakk] from comment #46)
> We're doing our last FF30 betas next week.  From reading through this bug it
> seems like we have a few options but disabling gfx.xrender solving the issue
> (and what is the resulting experience for users when this is done?) makes it
> look like the most feasible option for FF30 if we were able to promote a
> Sumo article (and release note) about this to enable users who hit it to
> return to a usable state. Are there any other viable, low-risk alternatives
> that could be put into next week's Beta for testing?

I think Milan is in a better position to answer this.

Comment 50

[Milan Sreckovic [:milan] (needinfo for best results)]

The "disable gfx.xrender" is probably the only Beta sized option we have. I think it's worth exploring the blacklisting from Comment 42, so we can take a quick look at that and see how large of a change it would be, and if we're willing to take it. I'm going to guess a weak no, but it's probably worth a look.  Also, we may have the results from investigation Jeff mentioned in Comment 43 as soon as tomorrow (5/27).

Comment 51

[Lukas Blakk [:lsblakk] use ?needinfo]

Based on the workaround on comment 24 - wontfixing (again) and we'll do our best to make sure users can find that temporary 'fix'.  For 31/32 let's look at the suggestions in comment 50 - Milan can we get someone assigned to work on the proper fix here?

Comment 52

[Milan Sreckovic [:milan] (needinfo for best results)]

Assigning to Jeff as he's tracking the work that should make the whole xrender thing go away.

Comment 53

[Sylvestre Ledru [:Sylvestre]]

Jeffn any progress on this? Thanks

Comment 54

[Milan Sreckovic [:milan] (needinfo for best results)]

I should have given more information. The initial work is tracked in bug 1015218.

Comment 56

[Sylvestre Ledru [:Sylvestre]]

Due to the size of the pending patch in bug 1015218, this is going to be a wontfix for 31 too. Hopefully, it is going to be fixed for 32.

Comment 57

[Rüdiger Kupper]

> (My hesitance agreeing with disabling gfx.xrender.enabled
> application-wide is because I am unaware of the implications, e.g. affecting
> casual users' experience.)

Please not that disabling xrender is not a good "fix", as it comes at a cost:

Disabling xrender has strong effect on rendering speed over networked X connections (i.e., when X slient and server are not on the same machine). The effect is immediately noticeable and makes for a very bad user experience. Simply scrolling down a page is a pain: The page updates in waves flowing across the display.

We deploy firefox for 800 users in a terminal server setup (LTSP), and currently my users can chose between two bad alternatives: Have the URL bar covered by boxes, or have extremely slow scrolling.

Unfortunately, the intel chip set in question is rather popular in these settings. Institutions like ours (school) often use old and cheap machines for thin clients, connecting to a few powerful servers over X. Many of those old machines are equipped with that chip set. 

Please consider finding a better fix! Thanks and Regards, Rüdiger

Comment 58

[Sylvestre Ledru [:Sylvestre]]

Like I said in comment #56, the patch in bug 1015218 is too big.
We will let the patch ride the trains with 34. Updating the tracking flags accordingly.

Comment 59

[Brent]

Put me down as one more user who is affected.  I ran into this bug today in Tinycore Linux (v 5.3) on an old 32bit 2GHz Celeron PC with Intel integrated graphics (845G).  Tinycore comes with Firefox 21.  Firefox 21 is not affected by this bug.  I was able to have Firefox 31 by using "firefox-get", a script that Tinycore provides.  And Firefox 31 shows colored squares in the URL bar.  Toggling gfx.xrender.enabled to "false" fixes the problem.

Comment 60

[LAZA]

Firefox 34.0 still unusable in combination with Ubuntu and Guest account!
So the machines used for Internet-Café are useless...

Will this fixed *at least* for the 14.04 LTS release(s) or must i change the browser after the upgrade from 12.04.5 LTS?
A clear statement about the future would be a clarification.

Hardware:
FUJITSU SIEMENS D1534
Intel(R) Celeron(R) CPU 2.40GHz
82865G Integrated Graphics Controller - driver=i915 latency=0


https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1314924

Comment 61

[Christopher Chavez]

(In reply to LAZA from comment #60)
> Will this fixed *at least* for the 14.04 LTS release(s) or must i change the
> browser after the upgrade from 12.04.5 LTS?
As I mentioned just now on Launchpad, this should be fixed in Ubuntu LTS by an upgrade of xserver-xorg-video-intel in the 14.04.2 point release.

Comment 62

[Christopher Chavez]

Is it still worthwhile to consider a fix if we can find out it's the case that most of the distributions out there are planning to upgrade to their Intel drivers to at least 2.99.911?

Comment 64

[u279076]

Lee, this was assigned to you some months ago. Is this still an issue worth tracking?

Comment 65

[Lee Salzman [:lsalzman]]

Never had time to look into this; no idea what's going on offhand.

Comment 66

[Lee Salzman [:lsalzman]]

Since we have several confirmations in this thread that disabling xrender fixed the issue, and that as of bug 1180942 and bug 1241832, we don't actually use xrender anymore by default, this should be a non-issue. Closing this one out.

Comment 67

[Christopher Chavez]

Should this instead be marked as RESOLVED FIXED? The fix for this issue indeed appeared between versions 45 and 46, and not because of gfx.xrender.enabled being set to false, since setting it to true does not cause the issue to reappear in version 46 or later (even though setting it to false in version 45 or earlier did prevent the issue).