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.

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.

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

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?

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" } },

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: ubufox@ubuntu.com 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

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.

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.

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

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

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.

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.

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.

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

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

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

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.

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!

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

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

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.

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

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

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

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

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.

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?

Can we bisect this?

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.

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

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?

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

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.

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

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)

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

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

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

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

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

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.

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.

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

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

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

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

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?

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

Jeffn any progress on this? Thanks

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

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.

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

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.

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.

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

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

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?

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

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

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.

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