Open Bug 547983 Opened 14 years ago Updated 2 years ago

Possible javascript rendering and windowing problem,

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Version:
3.6 Branch
Platform:
x86_64
Linux
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: Leo.Smith, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2) Gecko/20100222 Firefox/3.6
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2) Gecko/20100222 Firefox/3.6

One one site, which uses popup windows on mouse overs (or possibly on hovers) scrolling away using the mouse wheel ONLY does not always close ALL of the popup window. Some or all of it is left, and weirdly, mousing over the bits that are left after other mouseover events have 'cleaned it up' partially still gives the text..as a new popup.

I can't reproduce this reliably at all. 

It doesn't happen on 3.6 on windows XP test virtual machine, only on Native Debian stable lenny setup. 

It intermittently happens with Debian's iceweasel port as well.

I was thinking it was merely a rendering issue, but the fact that the bits of popup left are still responding to mouseovers, suggests its some subtle javascript bug. I.e. these are not juts screen artefacts, but actual fragments left inside the browser itself.

I hate reporting so vague a problem. 


Reproducible: Sometimes

Steps to Reproduce:
1.Firstly, the actual setup,which may be relevant., is latest (23/3/10) Debian stable lenny AM64 code. The graphics hardware is onboard Intel. I downloaded and compiled the Firefox 3.6 from mercurial sources. 

2. Go here
http://www.rcgroups.com/modeling-science-136/
and when the page has loaded, move the mouse over a thread title: On the first entrance to the page, this seems to be nearly 100% consistently able to leave a grey box behind when most of the popup disappears again. Of course on checking again, its not doing it.

I ran firefox from the command line: no errors showed there.Nothing unusual shows up in the error console either.

3.If you succeed in getting the grey box, mosuing over it show the text all over again. 

4. If you get another popup to overlay it, and the collapse that one, the part overlaid disappear,, but the parts that are left STILL GENERATE THE POPUP TEXT.


Actual Results:  
See above. Sometimes, but not reliably, bits of a window are left behind that respond to javascript mouse overs or hovers

Expected Results:  
popup window should close reliably.
The appearance of this bug seems to be time related: If I close all instances of Firefox, its fine for a while.

So POSSIBLY a memory leak of some sort in the javascript engine?

I have confirmed its not site related: Other sites show the same issues.
Still happens in safe mode Tyler.

One key seems to be leaving this site running for some time

http://www.tvguide.co.uk/ 

It's intensely scripted.
this popped up in the error output from safe mode

(firefox-bin:31985): Gdk-WARNING **: XID collision, trouble ahead

I am not clued up enough to say if it is relevant.
Further information in this one.

Its still extant in 3.6.2
Its probably an interoperability issue with the GTK library...something Firefox does gives it indigestion, and after that, the visible errors show.
It is not present on MAC OS-X or Windows ports of 3.6.
I have not seen it reported on 32 bit Linux systems.

What I said about it being a javascript issue is wrong: it is purely a screen rendering  issue. BUT it is only produced by certain sorts of javascript events..

It seems to be triggered or exacerbated by using Flash, and/or more open tabs or browser instances.

There is a bug report out on the GTK library bug system as well.

see https://bugzilla.mozilla.org/show_bug.cgi?id=547983
Oh, safe mode doesn't fix it either.
I have some further information on this one.

Following some suggestions made on a GTK bug report, I set the native windows environment variable, and this changed the character of the effect.

Instead of grey background boxes being left behind on an javascript popup, the whole box, text and all, was left.

So the grey box artifact seems to be something to do with the client windows bit. 

However the failure to register mouse events on a scroll down that takes the cursor off the active mouseable area followed by any mouse movement, seems a bug somewhere at the javascript level.

Normally if you mousesover to get a popup, and scroll away, the element will stay UNTIL a mouse movement is detected. 

What I suspect is happening here, is that internally the element is now tagged as invisible, even though it isn't - its still onscreen - and therefore not relevant to mouse events as such.

The fact that it does seem limited to Linux implementations with the GTK  library is however very strange.

Possibly what this means is that instructions to clear the area are in fact being sent to GTK, but it is ignoring them - partially when used with client windows, and totally when using native windows.
scrub the javascript issues: The more I test this the more it looks like simply a code incompatibility between the firefox and the GTK, in that  for whatever reason, sometimes screen areas are not being correctly replaced.

The XID collisions are also possibly a red herring: other pages are generating them. I can reproduce the effect without seeing any.

My final conclusion is that this is an interoperability problem between the mozilla libraries and the GTK libraries. 

I don't know who is responsible to fix that tho.
Interesting update.

I have recompiled Firefox to 3.6.3 level today, and so far, this problem has not reappeared.

The fact that it was intermittent, and generally occurred after a lot of windows were opened and or a lot of JavaScript was in play, suggests there may have been a memory leak somewhere that caused it.

I am a bit disappointed that no one seems to regard this bug as even worth testing.

I will leave the thing open until a few problem free days have elapsed.
This gets sillier. It wasn't 3.6.3 that cleared the bug: it was just that I happened to have a gnome web browser running at the same time. As soon as I launch that, the problem goes.

I am totally utterly and completely confused.
I think I may have found the answer to this: The fact that no one else seems to have seen it was a bit of a pointer.

Anyway, after further upgrades my system was exhibiting sporadic lockups to the X server.

A lot of googling reveals that there are bugs in the Intel video driver/x-server that are concerned with acceleration modes. To fix these, I tried using a different acceleration model in the Debian X-server.

I added this

	Option "AccelMethod" "XAA"

To the "Device" section of xorg.conf and it seems to have fixed the problem.

And the xorg.0.log no longer reports ring buffer failures and fatal lock-ups either.

If the problem proves to be completely resolved, I will formally close it in a day or three.

It would seem to be a complex interaction between firefox, the x server and the intel video driver, which I will report to the package maintainers there if it seems to be resolved.
Version: unspecified → 3.6 Branch
Can anyone reproduce this issue on a current Firefox version (23, 24 etc)?

WFM on:
Mozilla/5.0 (X11; Linux x86_64; rv:25.0) Gecko/20130722 Firefox/25.0
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.