Invalid drawable error in console after starting Firefox

RESOLVED FIXED in mozilla21

Status

()

Core
Graphics
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: virgil, Assigned: BenWa)

Tracking

({regression})

18 Branch
mozilla21
x86
Mac OS X
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
Created attachment 685604 [details]
Invalid drawable error in Terminal

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.

Updated

5 years ago
Blocks: 539356
Keywords: regression
(Assignee)

Comment 2

5 years ago
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
(Assignee)

Comment 5

5 years ago
Ok, I'll run it through try.
(Assignee)

Comment 6

5 years ago
Created attachment 707278 [details] [diff] [review]
patch

https://tbpl.mozilla.org/?tree=Try&rev=7412bb2c3e7a

Waiting for green to r?
Assignee: nobody → bgirard
Status: NEW → ASSIGNED
(Assignee)

Comment 7

5 years ago
https://tbpl.mozilla.org/?tree=Try&rev=0f7d640fa75f
(Assignee)

Updated

5 years ago
Attachment #707278 - Flags: review?(matt.woodrow)
Attachment #707278 - Flags: review?(matt.woodrow) → review+
(Assignee)

Comment 8

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/0415a9f8699a
https://hg.mozilla.org/mozilla-central/rev/0415a9f8699a
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
(Reporter)

Comment 10

5 years ago
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.