Last Comment Bug 540911 - div with position:fixed over an iframe flickers horribly when scrolling
: div with position:fixed over an iframe flickers horribly when scrolling
Status: RESOLVED WORKSFORME
: regression, testcase
Product: Core
Classification: Components
Component: Layout: View Rendering (show other bugs)
: Trunk
: x86 Linux
: -- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-01-20 12:26 PST by Jonathan Protzenko [:protz]
Modified: 2010-11-04 14:15 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-
wanted
-
wanted


Attachments
New symptoms on Fx 4.0b2 (30.07 KB, image/png)
2010-08-08 11:53 PDT, Jonathan Protzenko [:protz]
no flags Details

Description Jonathan Protzenko [:protz] 2010-01-20 12:26:17 PST
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2) Gecko/20100105 Firefox/3.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20100120 Minefield/3.7a1pre

I first noticed this bug on Thunderbird while working on one of my extensions. I created a testcase that demonstrates the issue. Issue is present on Fx 3.6, latest-trunk, on Tb 3.0.x and 3.1.x.

From the Error Console, run:

window.open("http://jonathan.protzenko.free.fr/testcase/test.xul", "", "width=400, height=400, chrome");

Try scrolling a little bit. The blue part flickers awfully.

Reproducible: Always




The example is basically what my extension does with the "thread summary" in Thunderbird. One funny thing is that when I scroll the thread summary a lot in Thunderbird (with the 3-pane view activated), besides issues with flickering, some scroll events are forwarded to the *message list* (the part above the thread summary), not the <browser> that contains the thread summary... very weird.

I assigned this to "General" as I have no idea which component this is related to.

There seems to be no issue if the testcase is viewed in a regular tab in Firefox. I'm running a regular Debian/testing and I manage my own copies of Firefox and Thunderbird (official builds) if that's any help.
Comment 1 Ria Klaassen (not reading all bugmail) 2010-01-20 14:23:45 PST
Confirmed on Windows Vista for latest trunk and latest Firefox 3.6.
Regression on 21 July 2009 , probably by the Compositor patches.
Comment 2 Mike Beltzner [:beltzner, not reading bugmail] 2010-01-20 23:34:02 PST
Would take a patch for the 1.9.2 branch, but won't block a release.
Comment 3 Jonathan Protzenko [:protz] 2010-04-14 01:01:06 PDT
This bug is getting worse. Here's what happens now (new testcase):

window.open("http://jonathan.protzenko.free.fr/testcase2/testcase.xul", "", "width=400, height=400, chrome");

Once again, you must open this from the Error console (not a new tab in the browser), and scroll down a little bit.

Here's what it looks like (confirmed on latest-1.9.2 both on Linux and Windows and Minefield 3.7a4 on Linux):
http://jonathan.protzenko.free.fr/testcase2/test.png

I don't think this is a z-index issue or whatever. Moreover, it renders properly in a browser tab but wrongly when opened in a standalone window which is imho very strange.
Comment 4 Jonathan Protzenko [:protz] 2010-04-28 11:29:29 PDT
Here is a very minimal testcase (26 lines). It is self-contained, and only depends on another file being viewed inside the iframe (that file contains only lipsum for this testcase).

window.open("http://jonathan.protzenko.free.fr/testcase3/testcase.xul", "", "width=400, height=200, chrome");

The bug is present with the chrome parameter, the bug is absent if you remove the chrome parameter to the "open" call.

The bug is present if you use a XUL iframe, the bug is absent if you use a regular HTML iframe, regardless of the chrome parameter.
Comment 5 Jonathan Protzenko [:protz] 2010-04-28 11:43:02 PDT
I'd like to give some more context regarding this bug. Thunderbird 3.1 is about to enter the final stages of completion, and the bug is still present in Gecko 1.9.2.

I'm the author of a Thunderbird extension called "GMail Conversation View" that basically displays a conversation view of emails (see [1] for eye-candy), including your own emails "à la GMail".

[1] http://jonathan.protzenko.free.fr/gcv2.png

It's not an extension with a big user base (~6000 users at the time) but I feel like it has the potential to improve Thunderbird a little bit. However, while my extension only suffered version #1 of this bug with Thunderbird 3.0 (the one that flickers), Thunderbird 3.1 renders it completely unusable (exhibits version #2 of the bug). This means scrolled messages hide the conversation title completely, and also hide buttons that are essential to the navigation.

I feel like this is going to be very frustrating if I were to tell my users not to upgrade to Thunderbird 3.1, or even worse, to stop using my extension (as you may guess, I've put a huge amount of time and effort on this).

Roc, would you happen to have a workaround in mind? I've played with various settings but I'm totally clueless as to how I can
i) workaround the issue and
ii) still use a XUL iframe with type="content".

The iframes are displayed in a <browser> that's inside the main Thunderbird window (namely, browser#multimessage).

I'd be very much satisfied by a "hack" :-).

Thanks!

PS: I just confirmed the latest testcase fails on comm-central
Comment 6 David Ascher (:davida) 2010-04-28 11:46:13 PDT
As a bit of additional bkgnd, it feels to me like this bug is likely going to be problematic for any display of emails (which pretty much have to be in iframes) in any HTML-like display.  This is a high-value use case for Thunderbird-the-platform.
Comment 7 Jonathan Protzenko [:protz] 2010-04-28 12:07:16 PDT
Here's another testcase, for the version of the bug that flickers. I'm not filing a separate bug since I have the feeling that those two testcases are extremely similar. This is also confirmed on comm-central on Linux 32-bit.

window.open("http://jonathan.protzenko.free.fr/testcase4/test.xul", "", "width=400, height=400, chrome");

For the record, I'm slightly more interested in the testcase from comment 4 being fixed :).
Comment 8 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-04-28 14:40:42 PDT
Try adding a "transparent" attribute to your XUL iframe.
Comment 9 Jonathan Protzenko [:protz] 2010-04-29 01:01:19 PDT
Amazing, I wasn't even aware that such an attribute existed. That turns version #2 (the one that renders the iframe *over* the blue <div>) into version #1 (the one that flickers). So that leaves us with the flickering issue.
Comment 10 Jonathan Protzenko [:protz] 2010-04-29 11:59:53 PDT
Just to report additional information. The <xul:iframe>s live in the multimessage pane, the part of Thunderbird that creates a HTML summary when you select a collapsed thread (actually, it's a <xul:browser>).

The transparent attribute indeed alleviates the painting issue as mentioned in comment 9, but scroll events are still forwarded upwards through the <xul:browser> all the way up to the main mail window. This results in the message list scrolling while the mouse cursor is still over the multimessage pane. This goes on par with the flickerings.
Comment 11 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-04-29 16:17:33 PDT
OK, let me just confirm --- with the "transparent" attribute, the situation on Thunderbird 3.1 is no worse than on Thunderbird 3.0?
Comment 12 Jonathan Protzenko [:protz] 2010-04-29 22:32:47 PDT
Exactly :)
Comment 13 Jonathan Protzenko [:protz] 2010-08-08 11:53:19 PDT
Created attachment 463946 [details]
New symptoms on Fx 4.0b2

For the record, this bug just got worse in Firefox 4.0 b2.

If you consider the first testcase:
- when rendered in a separate window, not only do the blue part flicker, but now the <iframe> contents are *blurred*
- when rendered in a tab, the testcase exhibits none of the issues above

It was kind of surprising, but I double-checked. Here's a screenshot that demonstrates the issue. Left part is the first testcase rendered in a tab. Right part is the first testcase rendered in a separate XUL window launched with the JS line I gave in comment #0. The fonts are blurrier in the right part.

I have no idea whether this is related, but I thought I'd let you know.
Comment 14 Jonathan Protzenko [:protz] 2010-11-04 01:51:18 PDT
Roc, any plans for tackling this in the 2.0 timeframe or are you still busy with other stuff? (I guess the answer is you're still busy, but who knows? :-)).
Comment 15 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-11-04 02:31:54 PDT
This should be fixed on trunk already. You're saying it's not? What platform? What does about:support say about GPU acceleration?
Comment 16 Jonathan Protzenko [:protz] 2010-11-04 05:07:31 PDT
Completely fixed. I'm still running comm-1.9.2 for my work which means I hadn't realized this had actually been fixed (is that a side effect of retained layers?). Seeing no activity on the bug, I thought nothing had changed in the meanwhile.

While I'd appreciate a fix for 1.9.2, I guess there's not much hope for it... ?
Comment 17 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-11-04 14:15:22 PDT
Correct!

Note You need to log in before you can comment on or make changes to this bug.