Open Bug 716036 Opened 12 years ago Updated 2 years ago

css z-ordering renders invisible text on google search page

Categories

(Core :: Layout, defect)

9 Branch
ARM
Linux
defect

Tracking

()

People

(Reporter: achiang, Unassigned)

Details

Attachments

(5 files)

Attached image ff-invisible.png
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7

Steps to reproduce:

Type into Google home page search box, with Google's Instant Search feature turned on.


Actual results:

The text that I typed is invisible, the autocompleted text is visible in a silver color, and the suggestions are also visible.


Expected results:

The text that I typed should have been visible too.
See ff-invisible.png for an example of the broken behavior. In it, you can see the CSS element input#lst-ib.gsfi has z-index: 5.

But two elements down, the <div class="gsfi" only has z-index: 2, which causes the "am" to be invisible, as the input element also has color: transparent.

Additionally, please ignore the User Agent: included in the above description. The User Agent with which I can reproduce is:

Mozilla/5.0 (X11; Linux armv7l; rv:7.0.1) Gecko/20100101 Firefox/7.0.1 Firefox/7.0.1
Observe that if only a single letter is typed into the input form, it is visible.
Attached image hacked z-index
Finally, using Firebug to hack the z-index of the <div class="gsfi"> to give it a value of 6, observe that the typed letters are now visible again.

Unfortunately, this behavior does not occur on modern Firefox 10, even with the exact same stylesheet; we've only seen it on this older Firefox 7.
The other factor that can fix this is to change the color attribute of the input form to 'black' from 'transparent'.
This is now confirmed to affect Firefox 9 as well, using the build from here:

http://ports.ubuntu.com/pool/main/f/firefox/

And more specifically, on Ubuntu 10.04, so this deb:

http://ports.ubuntu.com/pool/main/f/firefox/firefox_9.0.1+build1-0ubuntu0.10.04.1_armel.deb
Version: 7 Branch → 9 Branch
Component: Untriaged → Layout
Product: Firefox → Core
Hey Alex,

I doubt there's much action to take here unless you can reduce this to an HTML test case. Could you provide one? This is a bug that only occurs on desktop ARM and not desktop i386, right?

Joe, can you think of any platform differences in layout that might trigger text to disappear?
There shouldn't be any platform differences in layout per se, but when it comes to font metrics, etc, all bets are off.

Alex, are you certain that exactly the same page is being served to Firefoxes 9 and 10? Google regularly sends different HTML, JS, etc.

You can test this by using a tool like Fiddler or Charles <http://www.charlesproxy.com/> to capture the problematic web content, then replay it to Firefox 10 and see if the problem still reproduces.
So, this doesn't actually look like it's a problem with stacking order. What I've found so far is:

- The input element on the Google search page is styled with a transparent background, and transparent text, with z-index: 5
- There is a div element with style="z-index: 2; color: black" which actually displays the characters we are typing
- There is another div element with style="color: silver" for displaying the autocomplete text.

What is happening on the armel machine which isn't working is, the text in the input element isn't really transparent (it's white!), which means that it's masking the text in the div element below. This is why playing with the stacking order in Firebug appears to fix it.

This can be seen quite easily by changing the background color of the input element from transparent to black. On a working machine, the entire input box goes solid black (as expected). On our broken machine, the input box goes black with the text clearly visible in solid white.
Component: Layout → Keyboard: Navigation
QA Contact: untriaged → keyboard.navigation
Attached file Test case
This reproduces it quite easily.

If you type in to the input box, you shouldn't see any characters. On our problematic machine the first character is transparent, but when you type a second character, they both turn white (and all further characters entered after this are white too)
Component: Keyboard: Navigation → Layout
QA Contact: keyboard.navigation → layout
Hardware: x86_64 → ARM
Oops, sorry about the change of component there. That was not intentional :)
Unless I'm missing something obvious, it would appear that this might be a problem in cairo. When rendering the glyphs in the test case, the cairo context always has a transparent source and the operator is always CAIRO_OPERATOR_OVER, yet cairo_show_glyphs is drawing opaque glyphs.
This behaviour is actually dependent on the X display. If I run my x86-64 build over ssh on the arm device, then I get the same behaviour.

Anyway, I have a regression window for this:

Good - http://hg.mozilla.org/mozilla-central/rev/836aa9658341
Bad - http://hg.mozilla.org/mozilla-central/rev/831f8e040f38

Bisect time :)
Was dreading this:

The first bad revision is:
changeset:   70161:acb4e51fa8a6
user:        Jeff Muizelaar <jmuizelaar@mozilla.com>
date:        Thu Mar 10 14:52:15 2011 -0500
summary:     Bug 562746. Update cairo to 1.10.

Fun :(
Ok,

baaf312e047a9bea6f54e63cd6534c2ed7448523 is the first bad commit
commit baaf312e047a9bea6f54e63cd6534c2ed7448523
Author: Andrea Canciani <ranma42@gmail.com>
Date:   Mon Apr 19 09:53:00 2010 +0200

    pattern: remove content field from solid patterns
    
    The content field in solid patterns had ill-defined semantic (or no
    semantic at all), thus it can be removed.

:040000 040000 bbad22142ae17936b993f04666385e8175c52a9f 7ea72f280dc393ebc92adf47f6f73b7b7f770cf0 M      src

So, it's this which breaks it: http://cgit.freedesktop.org/cairo/commit/?id=baaf312e047a9bea6f54e63cd6534c2ed7448523
Ok, so one thing that this commit changes is that the transparent source pattern used to be created with a cairo_content_t parameter = CAIRO_CONTENT_COLOR_ALPHA (see http://cgit.freedesktop.org/cairo/tree/src/cairo-pattern.c?id=ef5f9b5c61750207947587173d21b46e2d299f33#n586), and this was passed to _cairo_surface_create_similar_solid() when creating the source surface.

With this patch, this no longer happens. Instead, calling _cairo_color_get_content() on the transparent color on the source pattern returns CAIRO_CONTENT_ALPHA and this is passed to _cairo_surface_create_similar_solid(). This means that we now create the source surface with a different depth compared to the destination surface (see http://cgit.freedesktop.org/cairo/diff/src/cairo-surface.c?id=baaf312e047a9bea6f54e63cd6534c2ed7448523), and this seems to break it.

Making this small change restores the old behaviour, but I'm not sure if that's actually a real fix:

diff --git a/src/cairo-color.c b/src/cairo-color.c
index 6bc1705..ae5d276 100644
--- a/src/cairo-color.c
+++ b/src/cairo-color.c
@@ -219,7 +219,8 @@ _cairo_color_get_content (const cairo_color_t *color)
 
     if (color->red_short == 0 &&
 	color->green_short == 0 &&
-	color->blue_short == 0)
+	color->blue_short == 0 &&
+        color->alpha_short != 0)
     {
         return CAIRO_CONTENT_ALPHA;
     }

I'm not sure of the best approach to fix this. Karl, what are your thoughts?
Aaah, and as expected, rendering any transparent text in Firefox triggers the fallback path in cairo (_cairo_surface_fallback_show_glyphs), because the _surfaces_compatible() check in cairo-xlib-surface.c fails due to the source/destination surface depths being different.
I have only a superficial understanding but sounds like there is a bug in the fallback path that wasn't triggered prior to that changeset.

As diagnosing that bug may be difficult, effectively reverting part of the changeset by removing the CAIRO_CONTENT_ALPHA block may be workaround.
I see a couple of _cairo_pattern_init_solid calls that were passing CAIRO_CONTENT_ALPHA though and I don't know what would be lost there by effectively changing to COLOR_ALPHA.

I imagine the same bug could happen with color->alpha_short != 0.

(Confirming based on the detail reported.)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Is it possible to check that this hasn't been fixed in git cairo?
Yes, this still seems to affect git cairo. I guess that the bug in the fallback path could actually be in pixman though? I'll try a git build of that too
Just to update - comment 16 was actually a red herring (something else was triggering fallback paths in cairo, but it wasn't this). In fact, this appears to actually be a bug in the xrender implementation. If I add a check at the top of _categorize_composite_operation() to return DO_UNSUPPORTED if the source pattern is solid and has a content type of CAIRO_CONTENT_ALPHA, then this forces this particular case to use the non-xrender fallback, which works fine.

This might be a good workaround for this case. The difficult bit is figuring out what xrender implementations are broken. So far, this seems to be specific to the X version in Ubuntu 10.04, when using EXA (not using EXA also fixes it) and with a color depth of 16 bits (AFAICT, we've never had any other reports for this problem).
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: