User Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0a2) Gecko/20120110 Firefox/11.0a2 Build ID: 20120110042006 Steps to reproduce: I went to Bing Maps (link from the Bing homepage): http://www.bing.com/maps/?v=2&cp=43.50529205553157~4.723239421844476&lvl=10&dir=0&sty=h&where1=Plage%20de%20Piemanson%2C%20Bouches-du-Rh%C3%B4ne%2C%20France&FORM=hphot4&mkt=fr-fr Then I tried to move the map. Actual results: My X locked down. The mouse could still move, but the cursor stayed the same everywhere and I could not do any action on either Firefox or my Window Manager (like clicking on the cross to stop Firefox, or switching desktops, etc.) I could kill X using "ctrl alt pr.screen k" and then X restarted, which is different than other bugs I had before (though this difference could be because I also upgraded my system since then). Sorry, I have not much more information; I tried to run Firefox and redirecting its output to a file, there was no interesting output (only one line), same for the X log file. My driver is "nouveau" so this doesn't support hardware accelerations. Expected results: Nothing :-)

This is basically http://timeless.justdave.net/blog/143/ if your X server really died.

Yes, I really do thing the problem is in the nouveau driver, but, well, I don't know where to begin with.

is X starting to work again if you kill the Firefox process via commandline ?

I couldn't test this this morning but will test it asap.

X works again when I kill Firefox. However, it was kind enough to give me a stacktrace : [2802460.875] 0: /usr/bin/Xorg (xorg_backtrace+0x37) [0xb76ef197] [2802460.875] 1: /usr/bin/Xorg (mieqEnqueue+0x185) [0xb76cd5f5] [2802460.875] 2: /usr/bin/Xorg (0xb756a000+0x4fd35) [0xb75b9d35] [2802460.875] 3: /usr/bin/Xorg (xf86PostMotionEventM+0xf9) [0xb75f7fa9] [2802460.875] 4: /usr/bin/Xorg (xf86PostMotionEventP+0x86) [0xb75f80a6] [2802460.875] 5: /usr/lib/xorg/modules/input/evdev_drv.so (0xb6225000+0x2cee) [0xb6227cee] [2802460.875] 6: /usr/lib/xorg/modules/input/evdev_drv.so (0xb6225000+0x3e0d) [0xb6228e0d] [2802460.875] 7: /usr/bin/Xorg (0xb756a000+0x78791) [0xb75e2791] [2802460.875] 8: /usr/bin/Xorg (0xb756a000+0x9ff62) [0xb7609f62] [2802460.875] 9: (vdso) (__kernel_sigreturn+0x0) [0xb754c400] [2802460.875] 10: /usr/lib/i386-linux-gnu/libpixman-1.so.0 (0xb73d8000+0x15fa2) [0xb73edfa2] [2802460.875] 11: /usr/lib/i386-linux-gnu/libpixman-1.so.0 (0xb73d8000+0x1153a) [0xb73e953a] [2802460.875] 12: /usr/lib/i386-linux-gnu/libpixman-1.so.0 (0xb73d8000+0x4f48b) [0xb742748b] [2802460.875] 13: /usr/lib/i386-linux-gnu/libpixman-1.so.0 (pixman_image_composite32+0x433) [0xb73ddc63] [2802460.875] 14: /usr/lib/i386-linux-gnu/libpixman-1.so.0 (pixman_image_composite+0xa6) [0xb73dddb6] [2802460.875] 15: /usr/lib/xorg/modules/libfb.so (fbComposite+0x201) [0xb6fd9ab1] [2802460.875] 16: /usr/lib/xorg/modules/libexa.so (0xb6fa8000+0x12c13) [0xb6fbac13] [2802460.875] 17: /usr/lib/xorg/modules/libexa.so (0xb6fa8000+0xf070) [0xb6fb7070] [2802460.875] 18: /usr/bin/Xorg (0xb756a000+0x10c7fb) [0xb76767fb] [2802460.875] 19: /usr/bin/Xorg (CompositePicture+0x21e) [0xb766929e] [2802460.876] 20: /usr/bin/Xorg (0xb756a000+0x10473c) [0xb766e73c] [2802460.876] 21: /usr/bin/Xorg (0xb756a000+0xffb91) [0xb7669b91] [2802460.876] 22: /usr/bin/Xorg (0xb756a000+0x3b6b7) [0xb75a56b7] [2802460.876] 23: /usr/bin/Xorg (0xb756a000+0x292aa) [0xb75932aa] [2802460.876] 24: /lib/i386-linux-gnu/i686/cmov/libc.so.6 (__libc_start_main+0xe6) [0xb7205e46] [2802460.876] 25: /usr/bin/Xorg (0xb756a000+0x295e9) [0xb75935e9]

I forgot the first line, which was : [2802460.875] [mi] EQ overflowing. The server is probably stuck in an infinite loop.

Please report that to you r x vendor

I just did. However I also did additional tests: this bug doesn't happen with current Firefox 10 beta. I saw on "about:support" that my graphic driver is blacklisted on FF10 but I'm not sure for FF11. On FF11, I see : WebGL Rendering: false Hardware accelerated Windows: 0 On FF10, I see something like "Gallium driver blacklisted". Anyway, even if my X driver has a bug, I think something should be done on Firefox side, at least blacklist something. Please tell me if I can test with some preferences set/unset.

Try it with Firefox in the Firefox safemode. The safemode disables the hardware acceleration while you are in the safemode. - http://support.mozilla.com/en-US/kb/Safe+Mode

ok, the bug happens also in Safe Mode.

Same on another Linux with an intel card (still no hw accel, the driver is too old). I have no PC with hw accel under Linux so I can't try further, but the problem seems to be more important than expected, and it happens with Xorg 7.5 (on my Intel box) and 7.6 (on my nvidia box). I got report of the same problem from someone using an ATI card (no hw accel).

On a Mac book pro running ubuntu (NVIDIA Corporation -- GeForce GT 330M/PCI/SSE2 -- 3.3.0 NVIDIA 280.13) I can't reproduce this bug. I have hw accel enabled Scrolling the map is very slow and very CPU intensive, but doesn't lock X.

Fabrice, do you confirm it wasn't slow in Firefox 10 ? Also, I saw that in my case, Xorg was taking 100% CPU. So maybe the only difference between you and me is that my computer is 8 years old and has only one core ?

I haven't checked with Firefox 10, but it's dead slow on a nightly.

Yep, I mean, if everything works like a charm in Firefox 10 for you too, maybe this could confirm we have the same problem. And that it isn't related at all to hw acceleration.

Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0 Confirming this with 11Beta3. 1. Start Firefox with clean profile. 2. Load bing.maps.com 3. Move the map. Firefox hangs on Ubuntu 11.10 for a good couple of seconds (over 20 for me every time). I reproduced this on two machines, both Ubuntu 11.10. This does not occur with Chrome or previous Firefox versions. Searching for a regression range.

I can't reproduce with any Firefox 10. This must have regressed while 11 was in Nightly. To look over this tomorrow. Time constraints today.

Could you add some information about your video driver, type of computer (like how many cores), etc ? I confirm that it doesn't happen for me with FF10.

Last good nightly: 2011-12-19 First bad nightly: 2011-12-20 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d75ebb37080e&tochange=2afd7ae68e8b Julian, Ubuntu 11.10 with Intel® Core™2 CPU 4400 @ 2.00GHz × 2, GeForce 8400 GS/PCI/SSE2, 64 bit system. As previously reported, this works fine on other browsers (Opera, Chrome) and there is no info that might suggest anything wrong in about:support. Don't use hardware acceleration.

The only thing I can see in there that might be related, however unlikely, is: http://hg.mozilla.org/mozilla-central/rev/27cc305a5a1a Do you think that's at all possible, roc?

Yes, definitely. (In reply to Virgil Dicu [:virgil] [QA] from comment #19) > As previously reported, this works fine on other browsers (Opera, Chrome) Opera and Chrome don't use X much for drawing, so they don't benefit from acceleration in X drivers but they also don't get affected nearly as much by bugs in X drivers. Due to the extremely low quality of most X drivers, that's probably the right decision, but it's hard to change pre-GTK3 (due to the need to use X to render native widgets in GTK2).

We could probably work around this bug by disabling prerendering in some situations, but it's not clear to me exactly what that condition should be.

What's the benefit to bug 702739 for Firefox desktop users? Is there anything preventing us from backing it out for FF11? Tracking and sending over to matspal in roc's absence (he r+'d bug 702739). We need to figure out what should be done here for the next FF11 beta (going to build 2/28 in less than a week).

I suspect Chris will be unhappy if we back it out. If I understand the above correctly, we still want the feature enabled for Android Fennec and B2G? and all non-Linux platforms? We probably have #ifdef knobs to do that selection, but I'm not sure which. Maybe MOZ_X11 and/or ANDROID ?

This is critically important for UIs on b2g (not just Mozilla's). Backing out bug 702739 would massively massively regress performance right before our big demo to the world. I don't quite understand the issue here. Is it buggy X drivers or too much prerendering or a combination thereof? The benefit in general for desktop FF is that same as for b2g, in non-degenerate conditions: less texture/surface churn and less repainting.

Chris, do you know a combination of #ifdef knobs to keep it enabled for b2g and Android, but disable it for "desktop Linux". I feel that's my only option here since I don't know enough about graphics to fix it. We need at least a safe workaround before 2/28 (per comment 23).

Bug 721905 indicates that Bing maps creates layers with huge visible regions. Maybe that is what is choking X here? Maybe we can put some sane limit on the size of layers that bug 702739 creates?

Or we could look into bug 721905 to see why that is happening in the first place.

We already restrict pre-rendering to frames that are the window size or smaller (modulo a small fudge factor). This of course falls down if there are hundreds or thousands of window-sized frames, but so does lots of other stuff. A layer-tree dump from bing maps would be very helpful. Even better, one from before the badness started happening and one from after. (In reply to Mats Palmgren [:mats] from comment #26) > Chris, do you know a combination of #ifdef knobs to keep it enabled for b2g > and > Android, but disable it for "desktop Linux". I feel that's my only option > here > since I don't know enough about graphics to fix it. We need at least a safe > workaround before 2/28 (per comment 23). Yes, but this optimization should be globally helpful. I'd like to find out what's falling over here. We can keep that as a last resort I guess.

Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0 beta 4 Reproducible also on Windows.

(In reply to Mihaela Velimiroviciu [QA] from comment #30) > Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0 beta 4 > > Reproducible also on Windows. Mihaela, can you elaborate on this statement? Windows does not use X11 so I'm curious by your statement.

(In reply to Chris Jones [:cjones] [:warhammer] from comment #25) > This is critically important for UIs on b2g (not just Mozilla's). Backing > out bug 702739 would massively massively regress performance right before > our big demo to the world. > > I don't quite understand the issue here. Is it buggy X drivers or too much > prerendering or a combination thereof? > > The benefit in general for desktop FF is that same as for b2g, in > non-degenerate conditions: less texture/surface churn and less repainting. Is b2g being demoed off of FF11? We're shipping XUL Fennec 10.0.3 in step with FF11 desktop, so that'll be unaffected as well. If we're only talking about gains in non-shipping products (and maintaining the current state on desktop), I'd prefer we just back out bug 702739. Regardless, we'll want to choose a path that ensures this bug is resolved in time for our 2/28 beta 5 go-to-build (5 days away).

If you can reproduce this bug, please test mozilla-beta (Fx11) build: https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mpalmgren@mozilla.com-567a216a196b/ or mozilla-central (Fx13) build: https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mpalmgren@mozilla.com-f9f8e9d356cd/ and let me know the results. Thanks.

I don't understand the "reference frame" in this code very well, but the original idea was to only prerender frames that were ~viewport size or smaller. Should we be checking the nearest widget size here instead? Very interested to see if your patch makes a difference.

The reference frame is the root root frame. It is the size of the top widget.

(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #31) > (In reply to Mihaela Velimiroviciu [QA] from comment #30) > > Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0 beta 4 > > > > Reproducible also on Windows. > > Mihaela, can you elaborate on this statement? Windows does not use X11 so > I'm curious by your statement. STR: 1. Load www.bing.com/maps 2. Select Bird's view 3. Resize/move the map Result: After a few operations, firefox stops responding: cannot use the map nor any browser chrome elements

(In reply to Mats Palmgren [:mats] from comment #33) > Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0 Tested both builds. The issue is no longer reproducible. Tried to move, zoom in bing maps, used bird eye view, aerial view. Sometimes the map takes longer to load in aerial/bird eye view, but this also occurs on Chrome and previous Firefox versions (tried with 10).

(In reply to Mats Palmgren [:mats] from comment #33) > If you can reproduce this bug, please test mozilla-beta (Fx11) build: > https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mpalmgren@mozilla. > com-567a216a196b/ > > or mozilla-central (Fx13) build: > https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mpalmgren@mozilla. > com-f9f8e9d356cd/ > > and let me know the results. Thanks. Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0 I cannot reproduce the issue with the try builds on Win 7.

(In reply to Timothy Nikkel (:tn) from comment #35) > The reference frame is the root root frame. It is the size of the top widget. Why does http://hg.mozilla.org/try/rev/00ec76a793da affect anything then? We surely can't be creating widgets with dimensions > 4096 pixels ...

Comment on attachment 601675 [details] [diff] [review] wallpaper I'd kinda like to know the answer to comment 39... but this is considered a temporary workaround until we can debug this properly and figure out what the real problem is?

Comment on attachment 601675 [details] [diff] [review] wallpaper Yeah, the first hunk is just wallpaper. The 2nd hunk is an optimization that can stay after we remove the wallpaper part.

Ok, let's split them up then, will reduce confusion for everyone.

(In reply to Alex Keybl [:akeybl] from comment #32) > Is b2g being demoed off of FF11? We're shipping XUL Fennec 10.0.3 in step > with FF11 desktop, so that'll be unaffected as well. If we're only talking > about gains in non-shipping products (and maintaining the current state on > desktop), I'd prefer we just back out bug 702739. > > Regardless, we'll want to choose a path that ensures this bug is resolved in > time for our 2/28 beta 5 go-to-build (5 days away). We've now missed the beta 5 go-to-build. We do not plan to take a forward fix for this issue. Nobody has addressed my previous comment above, so my assumption is that we plan to back out bug 702739. Please nominate ASAP.

Comment on attachment 601866 [details] [diff] [review] part 1, wallpaper r+ as a temp fix.

This is the backout patch for mozilla-beta in case we need it. Commit message: "Backout bug 702739 (cset 27cc305a5a1a and 89a8e26f1df0). r=tnikkel a=akeybl"

Comment on attachment 601879 [details] [diff] [review] Backout bug 702739 from mozilla-beta hg backout handled all of this without manual intervention except nsDisplayList.cpp. So I looked over those changes and they seemed fine.

Comment on attachment 601879 [details] [diff] [review] Backout bug 702739 from mozilla-beta [Approval Request Comment] Regression caused by (bug #): bug 702739 User impact if declined: bad performance on some sites (probably few) Testing completed (on m-c, etc.): none Risk to taking this patch (and alternatives if risky): Low-risk, but very likely re-introduces the bad performance bug 702739 was meant to fix (which is particularly bad for b2g/fennec, see Chris' comments above). The alternative is to take the wallpaper patch, which I think is quite low-risk. String changes made by this patch: none

Comment on attachment 601867 [details] [diff] [review] part 2, optimization So the idea is that GetVisualOverflowRect is the same as MatrixTransformRect(GetVisualOverflowRectRelativeToSelf) and we avoid a call to MatrixTransformRect in the ShouldPrerenderTransformedContent case?

Yes

Comment on attachment 601867 [details] [diff] [review] part 2, optimization I think I'm mistaken about this being equivalent - the final overflow area also has the contributions from nsIFrame::ComputePreserve3DChildrenOverflow and what we want here is just the transform area.

Comment on attachment 601879 [details] [diff] [review] Backout bug 702739 from mozilla-beta [Triage Comment] Backing out to a known good state - approved for Beta 11. B2G and Fennec would see the greatest regression, but neither product is shipping off of the FF11 branch.

https://hg.mozilla.org/releases/mozilla-beta/rev/1a40f4e22979 https://hg.mozilla.org/releases/mozilla-beta/rev/9e043e84ffa2

Please reopen original bug if you back this out.

It's only backed out on mozilla-beta (Fx11), it's not going to be backed out anywhere else as far as I know.

Comment 57 looked like the backout landed on mc hence my confusion.

No problem; you're absolutely right I should have updated bug 702739 with a notice about the backout for Fx11.

Just to let you know that I tested the try build for FF13 in Comment 33 and it fixes the bug for me. (I didn't really understand all that happened: backout of bug 702739 for FF11 and a real fix for FF13 ? What about FF12 ?)

The bug is still present in FF12 (Aurora branch).

The trunk patch doesn't apply since "Part 1" in bug 724189 isn't on Aurora.

Comment on attachment 602858 [details] [diff] [review] Wallpaper for Aurora (Fx12) [Approval Request Comment] Regression caused by (bug #): bug 702739 User impact if declined: bad performance on some sites (probably few) Testing completed (on m-c, etc.): similar patch baked on trunk for a few days Risk to taking this patch (and alternatives if risky): low risk String changes made by this patch: none

Comment on attachment 602858 [details] [diff] [review] Wallpaper for Aurora (Fx12) [Triage Comment] Low risk and fixes a bug tracked/unresolved in FF12. Approved.

Filed bug 733581 to figure out what the real problem is, per comment 39.

Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0 Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20100101 Firefox/11.0 Verified on Firefox 11 Beta 6 on Ubuntu 11.10. Zooming, moving the map in bing.maps works as expected. No hangs occurred. Also checked on Windows 7 and Mac OS.

verified on latest Aurora.