Moving the map in Bing Maps locks my X11

RESOLVED FIXED in Firefox 11

Status

()

Core
Graphics
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: julienw, Assigned: mats)

Tracking

(Depends on: 1 bug, {regression})

11 Branch
mozilla13
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox11+ verified, firefox12 verified)

Details

(Whiteboard: [11b3][qa!], URL)

Attachments

(3 attachments, 2 obsolete attachments)

(Reporter)

Description

5 years ago
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.
(Reporter)

Comment 2

5 years ago
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 ?
(Reporter)

Comment 4

5 years ago
I couldn't test this this morning but will test it asap.
(Reporter)

Comment 5

5 years ago
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]
(Reporter)

Comment 6

5 years ago
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
(Reporter)

Comment 8

5 years ago
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
(Reporter)

Comment 10

5 years ago
ok, the bug happens also in Safe Mode.
(Reporter)

Comment 11

5 years ago
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.
Component: Untriaged → Graphics
Product: Firefox → Core
QA Contact: untriaged → thebes
(Reporter)

Comment 13

5 years ago
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.
(Reporter)

Comment 15

5 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hardware: x86 → All
Whiteboard: [11b3]
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.
(Reporter)

Comment 18

5 years ago
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.
Keywords: regressionwindow-wanted
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.
Keywords: regressionwindow-wanted → regression
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.

Updated

5 years ago
Blocks: 702739
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).
Assignee: nobody → matspal
status-firefox11: --- → affected
tracking-firefox11: --- → +
(Assignee)

Comment 24

5 years ago
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.
(Assignee)

Comment 26

5 years ago
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.
OS: Linux → All
(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).
(Assignee)

Comment 33

5 years ago
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 ...
(Assignee)

Comment 40

5 years ago
Created attachment 601675 [details] [diff] [review]
wallpaper
Attachment #601675 - Flags: review?(tnikkel)
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?
(Assignee)

Comment 42

5 years ago
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.
Attachment #601675 - Attachment description: fix → wallpaper
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.
(Assignee)

Comment 45

5 years ago
Created attachment 601866 [details] [diff] [review]
part 1, wallpaper
Attachment #601675 - Attachment is obsolete: true
Attachment #601675 - Flags: review?(tnikkel)
Attachment #601866 - Flags: review?(tnikkel)
(Assignee)

Comment 46

5 years ago
Created attachment 601867 [details] [diff] [review]
part 2, optimization
Attachment #601867 - Flags: review?(tnikkel)
Comment on attachment 601866 [details] [diff] [review]
part 1, wallpaper

r+ as a temp fix.
Attachment #601866 - Flags: review?(tnikkel) → review+
(Assignee)

Comment 48

5 years ago
Created attachment 601879 [details] [diff] [review]
Backout bug 702739 from mozilla-beta

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"
Attachment #601879 - Flags: review?(tnikkel)
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.
Attachment #601879 - Flags: review?(tnikkel) → review+
(Assignee)

Comment 50

5 years ago
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
Attachment #601879 - Flags: approval-mozilla-beta?
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?
(Assignee)

Comment 52

5 years ago
Yes
(Assignee)

Comment 53

5 years ago
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.
Attachment #601867 - Attachment is obsolete: true
Attachment #601867 - Flags: review?(tnikkel)
(Assignee)

Comment 54

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/391ac2bb95bd
Whiteboard: [11b3] → [11b3][inbound]
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.
Attachment #601879 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
(Assignee)

Comment 56

5 years ago
https://hg.mozilla.org/releases/mozilla-beta/rev/1a40f4e22979
https://hg.mozilla.org/releases/mozilla-beta/rev/9e043e84ffa2
status-firefox11: affected → fixed
https://hg.mozilla.org/mozilla-central/rev/391ac2bb95bd
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Whiteboard: [11b3][inbound] → [11b3]
Target Milestone: --- → mozilla13

Comment 58

5 years ago
Please reopen original bug if you back this out.
(Assignee)

Comment 59

5 years ago
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 60

5 years ago
Comment  57 looked like the backout landed on mc hence my confusion.
(Assignee)

Comment 61

5 years ago
No problem; you're absolutely right I should have updated bug 702739 with
a notice about the backout for Fx11.
(Reporter)

Comment 62

5 years ago
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 ?)
(Reporter)

Comment 63

5 years ago
The bug is still present in FF12 (Aurora branch).
(Assignee)

Comment 64

5 years ago
Created attachment 602858 [details] [diff] [review]
Wallpaper for Aurora (Fx12)

The trunk patch doesn't apply since "Part 1" in bug 724189 isn't on Aurora.
Attachment #602858 - Flags: review?(tnikkel)
Attachment #602858 - Flags: review?(tnikkel) → review+
(Assignee)

Comment 65

5 years ago
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
Attachment #602858 - Flags: approval-mozilla-aurora?
Whiteboard: [11b3] → [11b3][qa+]
Comment on attachment 602858 [details] [diff] [review]
Wallpaper for Aurora (Fx12)

[Triage Comment]
Low risk and fixes a bug tracked/unresolved in FF12. Approved.
Attachment #602858 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(Assignee)

Comment 67

5 years ago
https://hg.mozilla.org/releases/mozilla-aurora/rev/4d6c44001fbf
status-firefox12: --- → fixed
(Assignee)

Updated

5 years ago
Depends on: 733581
(Assignee)

Comment 68

5 years ago
Filed bug 733581 to figure out what the real problem is, per comment 39.
Duplicate of this bug: 733324
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.
status-firefox11: fixed → verified

Updated

5 years ago
Duplicate of this bug: 721667
(Reporter)

Comment 72

5 years ago
verified on latest Aurora.
status-firefox12: fixed → verified
Whiteboard: [11b3][qa+] → [11b3][qa!]
You need to log in before you can comment on or make changes to this bug.