The default bug view has changed. See this FAQ.

div with position:fixed over an iframe flickers horribly when scrolling

RESOLVED WORKSFORME

Status

()

Core
Layout: View Rendering
RESOLVED WORKSFORME
7 years ago
7 years ago

People

(Reporter: protz, Unassigned)

Tracking

({regression, testcase})

Trunk
x86
Linux
regression, testcase
Points:
---

Firefox Tracking Flags

(blocking2.0 -, status2.0 wanted, blocking1.9.2 -, status1.9.2 wanted)

Details

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
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.
Confirmed on Windows Vista for latest trunk and latest Firefox 3.6.
Regression on 21 July 2009 , probably by the Compositor patches.
blocking1.9.2: --- → ?
blocking2.0: --- → ?
Component: General → Layout
Keywords: regression, testcase
QA Contact: general → layout
Version: unspecified → Trunk
Component: Layout → Layout: View Rendering
QA Contact: layout → layout.view-rendering
Would take a patch for the 1.9.2 branch, but won't block a release.
Status: UNCONFIRMED → NEW
blocking1.9.2: ? → -
status1.9.2: --- → wanted
Ever confirmed: true
blocking2.0: ? → -
status2.0: --- → wanted
(Reporter)

Comment 3

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

Comment 4

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

Comment 5

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

Comment 7

7 years ago
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 :).
Try adding a "transparent" attribute to your XUL iframe.
(Reporter)

Comment 9

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

Comment 10

7 years ago
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.
OK, let me just confirm --- with the "transparent" attribute, the situation on Thunderbird 3.1 is no worse than on Thunderbird 3.0?
(Reporter)

Comment 12

7 years ago
Exactly :)
(Reporter)

Comment 13

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

Comment 14

7 years ago
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? :-)).
This should be fixed on trunk already. You're saying it's not? What platform? What does about:support say about GPU acceleration?
(Reporter)

Comment 16

7 years ago
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... ?
Correct!
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Resolution: FIXED → WORKSFORME
You need to log in before you can comment on or make changes to this bug.