Closed Bug 815602 Opened 7 years ago Closed 7 years ago

Invalid drawable error in console after starting Firefox

Categories

(Core :: Graphics, defect)

18 Branch
x86
macOS
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla21

People

(Reporter: virgil.dicu, Assigned: BenWa)

References

Details

(Keywords: regression)

Attachments

(2 files)

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/18.0 Firefox/18.0 beta 1
Build ID: 20121121075611

Steps to reproduce:
1. Install Firefox in Applications directory
2. Open Terminal and run /Applications/Firefox.app/Contents/MacOS/firefox

Expected result:
Firefox should start and no error should appear in Terminal.

Actual result:
"firefox[nnnn:nnn] invalid drawable" error appears in Terminal, as soon as Firefox starts.

This error appears from Firefox 18.0 to Latest Nightly and Latest Aurora.


Last good nightly: 2012-09-28
First bad nightly: 2012-09-29

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=895f66c4eada&tochange=c09a0c022b2e
(The error message is also visible in Console.app, even if you don't launch Firefox via the command line.)

From my local builds:
  OK:  9f476b4ac1e1
  Bad: 23f1b8c7d17e

http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=9f476b4ac1e1&tochange=23f1b8c7d17e

Which is mostly DLBI stuff.
Blocks: dlbi
Keywords: regression
This is easy to catch by using 'break NSLog':
http://mxr.mozilla.org/mozilla-central/source/gfx/gl/GLContextProviderCGL.mm#434

Removing this line locally fixes the problem. We seem to set the view on every frame in nsChildView. I haven't taken the time to make sure that removing this line is safe.

Matt any though if the changes you made changed something with this?
I believe I added that when I made the refresh driver timing changes. From memory, we failed tests without it, getting an invalid framebuffer error/abort within GL layers.

Run it through try maybe?
Actually, I added the one in nsChildView.

This error is probably happening because we paint ThebesLayers (and thus create a GLContext) before the nsChildView is ready to draw for the first time.

Seems like a safe change to me
Ok, I'll run it through try.
Attached patch patchSplinter Review
https://tbpl.mozilla.org/?tree=Try&rev=7412bb2c3e7a

Waiting for green to r?
Assignee: nobody → bgirard
Status: NEW → ASSIGNED
Attachment #707278 - Flags: review?(matt.woodrow)
Attachment #707278 - Flags: review?(matt.woodrow) → review+
https://hg.mozilla.org/mozilla-central/rev/0415a9f8699a
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
Verified the fix for Latest Nightly using the STR from comment 0.

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:21.0) Gecko/20130205 Firefox/21.0
Build ID: 20130205031033
You need to log in before you can comment on or make changes to this bug.