Closed Bug 783106 Opened 10 years ago Closed 10 years ago

OOP + specific set of CSS properties causes text to be invisible

Categories

(Firefox OS Graveyard :: General, defect)

Product:
Firefox OS Graveyard
Component:
General
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking-basecamp:+)

Status:
RESOLVED WORKSFORME
Project Flags:
blocking-basecamp +

People

(Reporter: justin.lebar+bug, Unassigned)

Details

Attachments

(1 file, 1 obsolete file)

Testcase v2 (patch to Gaia template app)
4.88 KB, patch
Details | Diff | Splinter Review 
STR: Apply the attached patch to Gaia, then run B2G and open the UI test app.  It'll be empty, a black screen.

Now undo the change to apps/system/js/window_manager.js that the patch makes; this will cause the UI test app to run in-process.  Run B2G and open the UI test app again.  It's no longer blank: There's a bunch of links inside.  This is what it should look like.

What's particularly bizarre is that, if you remove the border-bottom-right-radius declaration in the CSS file for #foobar, the text shows up again.  The text also shows up if you remove the font-size declaration for #foobar > li, the text shows up.

The unmodified UI test app exhibits the same behavior; this patch is just an attempt to isolate things a bit.

Huh??
Attached patch Testcase (patch to Gaia) (obsolete) — — Splinter Review 
> STR: Apply the attached patch to Gaia, then run B2G and open the UI test app.  It'll be empty, a 
> black screen.

Although the screen appears empty, the text is still there, afaict.  You can click on the invisible links, and the "you're hovering over text" cursor shows up at the right times.
blocking-basecamp: --- → ?
We should be able to make this into a reftest.  Most likely the bug is already covered by existing tests that just aren't running ...
I get the same behavior when I copy this code into the template app -- works in-process, text is invisible (on a white background this time) out-of-process.
Maybe something to do with cross-process mask layers?
This is a testcase to the template app, instead of the UI test app.

We've also discovered that the font-size requirement was something of a red herring: The requirement is that the <ul> be long enough to show scrollbars.
Attachment #652254 - Attachment is obsolete: true
I thought there was an outside chance this was related to bug 783355, but the testcase works fine in rev 5c730c1f2274 on the otoro.  So that might be a hint for a starting point for a bisect.
It sounds like this has the potential to "break the web". It's also affecting various built-in apps. Dave mentioned that this is likely the reason that the "scanning for new media" dialog in the gallery app renders without text when running OOP.
blocking-basecamp: ? → +
Can you recreate this on desktop or Android? If you can then I can have look into it. I'm afraid I don't have a b2g setup (if needed I can work that out, but I'd rather avoid that if I can).
(In reply to Nick Cameron [:nrc] from comment #9)
> Can you recreate this on desktop or Android? If you can then I can have look
> into it. I'm afraid I don't have a b2g setup (if needed I can work that out,
> but I'd rather avoid that if I can).

I can reproduce this on desktop b2g on my Linux box.  (Building desktop b2g requires just a configuration flag in your mozconfig; see https://wiki.mozilla.org/Gaia/Hacking.)
I have b2g up and running on a mac, but could not reproduce this bug. I applied the patch to the Gaia directory and ran make there and rebuilt b2g for good measure, but did not see any change in the UI test menu. That menu rendered with rounded corners and visible text. (I'm assuming that settings like OOP and accelerated layers are the same on mac as Linux). Any idea for how to reproduce this?

Does the b2g browser use the same OOP architecture as Gaia? Have you been able to reproduce the behaviour on a webpage?
To be clear, with the "patch to Gaia template app", you need to open the template app, not the UI test app.

The patch does not apply against Gaia tip (rev 9c614e4d25b697b7cc4) because the template app is no longer in the OOP blacklist, but you can safely ignore that patch reject (git apply --reject).

I'm on slow wifi at the moment, so I'll let you know if I can reproduce once everything finishes downloading.
This works fine for me on my mac.  I can't reproduce the problem anymore, with any of the testcases.

I guess we fixed it?  :-/
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
(In reply to Justin Lebar [:jlebar] from comment #13)
> This works fine for me on my mac.  I can't reproduce the problem anymore,
> with any of the testcases.
> 
> I guess we fixed it?  :-/

Hmm, well that was easy, hopefully it will stay fixed.
Duplicate of this bug: 788193
You need to log in before you can comment on or make changes to this bug.