[OS X] [Hardware acceleration off] Websites flickering, partially dis- and reappearing, tabs missing

RESOLVED FIXED in mozilla2.0b10

Status

()

Core
Graphics
--
major
RESOLVED FIXED
7 years ago
8 months ago

People

(Reporter: nikarlo, Assigned: roc)

Tracking

({regression})

Trunk
mozilla2.0b10
x86_64
Mac OS X
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

(Whiteboard: [hardblocker])

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b9pre) Gecko/20110106 Firefox/4.0b9pre
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b9pre) Gecko/20110106 Firefox/4.0b9pre

Tabs are white (empty) when scrolling and when I select one of them sometimes doesn't work and still to last selected tab.
The same also with a new profile.

Reproducible: Always
Please run Firefox in Safe Mode (http://support.mozilla.com/en-US/kb/Safe Mode) to make sure no extension is causing this issue. Further please try to disable hardware acceleration in the advanced pane of the preferences. Would be nice if you could post the graphic card information from the Help | Troubleshooting page. Thanks.
Hardware: Other → x86_64
Version: unspecified → Trunk
(Reporter)

Comment 2

7 years ago
In safe mode is the same.
This is my graph info:
Adapter Description0x22400,0x20400 Vendor ID0000 Device ID0000 Adapter RAM Adapter DriversDriver VersionDriver DateDirect2D EnabledfalseDirectWrite EnabledfalseWebGL RendererNVIDIA Corporation -- NVIDIA GeForce 7600 GS OpenGL Engine -- 2.1 NVIDIA-1.6.26GPU Accelerated Windows0/1

Machine is a osx86 with retail snow leopard
I'm changing the summary to the one from bug 622901, which is the same issue.
Status: UNCONFIRMED → NEW
Component: Tabbed Browser → Graphics
Ever confirmed: true
Product: Firefox → Core
QA Contact: tabbed.browser → thebes
Summary: Tab is not show if scrolling, most of tabs is white and take time to show → [OS X] [Hardware acceleration off] Websites flickering, partially dis- and reappearing
blocking2.0: --- → ?
Keywords: regression, regressionwindow-wanted
Duplicate of this bug: 622901
Duplicate of this bug: 624118
Summary: [OS X] [Hardware acceleration off] Websites flickering, partially dis- and reappearing → [OS X] [Hardware acceleration off] Websites flickering, partially dis- and reappearing, tabs missing
Bug 624118 comment 0 has good steps to reproduce and a screenshot.
Duplicate of this bug: 623858
(Reporter)

Comment 8

7 years ago
How I can help you?
I must try to compile myself from a trunk?
Ran into this problem and tested it on nightlies.
Showed up in 2011-01-03 but not in 2011-01-02.

A similar issue, a line between the title bar and tab bar flickered showed up in 2011-01-02 though.
(In reply to comment #9)
> A similar issue, a line between the title bar and tab bar flickered showed up
> in 2011-01-02 though.

That's bug 621762.
I've bisected the checkins in the range, this is the cause of the regression:
http://hg.mozilla.org/mozilla-central/rev/b7d1bb50e829
Blocks: 363861
Keywords: regressionwindow-wanted
The bug originates in PushGroupAndCopyBackground (called from BasicThebesLayer::Paint): the call to cairo_paint fails. After that the context gets marked as being in an error state and everything falls apart.

The problem seems to be that we're trying to use a surface as source which can't be used in that way. Specifically, the surface "s" is the one we've constructed in -[ChildView drawRect:inContext:] (called "targetSurface" there) - in other words, it's the window buffer. However, the cairo quartz backend can only use offscreen buffers ("bitmap contexts") as source surfaces.
I don't know if there's a way at all to read back the pixels we've drawn into the window.
Duplicate of this bug: 623373
I see.

I guess we'll need to predict in advance whether we'll need PushGroupAndCopyBackground and if we will, use a manual backbuffer.
This obviously blocks.
blocking2.0: ? → betaN+
Actually the thing to do is allow PushGroupAndCopyBackground to fall back to just PushGroup if we can't copy the background. That's the conservative fix for the regression here.
Assignee: nobody → roc

Comment 17

7 years ago
I pasted a lot of info into Bug 623373 https://bugzilla.mozilla.org/show_bug.cgi?id=623373 - but yes both are the same bug
Created attachment 502455 [details] [diff] [review]
fix

This should fix it, although I don't have my Mac at home so I can't test it right now.

I wonder why this doesn't cause reftests to fail with acceleration off.
Attachment #502455 - Flags: review?(mstange)
Whiteboard: [needs review]
tryserver build will appear at http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/rocallahan@mozilla.com-cabf467b8766
(Reporter)

Comment 20

7 years ago
(In reply to comment #19)
> tryserver build will appear at
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/rocallahan@mozilla.com-cabf467b8766

I can't find your directory
(In reply to comment #18)
> This should fix it, although I don't have my Mac at home so I can't test it
> right now.

Yes, this fixes it.

+        if (s->GetAllowUseAsSource() &&
+            (s->GetContentType() == gfxASurface::CONTENT_COLOR ||
+             s->GetOpaqueRect().Contains(GetRoundOutDeviceClipExtents(this)))) {

I think instead of s->GetAllowUseAsSource() you need (s->GetAllowUseAsSource() || s->GetType() == gfxASurface::SurfaceTypeTee), otherwise the tee surface case further down won't ever be reached.

> I wonder why this doesn't cause reftests to fail with acceleration off.

Probably because reftests draw into a canvas, not into the window.

I don't think the gfxQuartzSurface.cpp hunk was supposed to be part of the patch.
Comment on attachment 502455 [details] [diff] [review]
fix

r=me with the comments addressed
Attachment #502455 - Flags: review?(mstange) → review+
Whiteboard: [needs review] → [needs landing]
Blocks: 624728
Whiteboard: [needs landing] → [needs landing][hardblocker]
Blocks: 625124
Duplicate of this bug: 625124
Duplicate of this bug: 625470

Comment 25

7 years ago
I think that this bug might be also what I'm seeing as the regression range is also from 2011-01-02 to 2011-01-03:

Loading a dialog in CKEditor for the second time doesn't show up until the page is clicked. Load http://ckeditor.com/demo and click for example in the smiley dialog, the first time behaves more or less correctly, but the second one will fail.

This fails in my macbook and works correctly in XP
Duplicate of this bug: 625912
http://hg.mozilla.org/mozilla-central/rev/4c3416fdc7b0
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing][hardblocker] → [hardblocker]
Target Milestone: --- → mozilla2.0b10
Duplicate of this bug: 626074
(Reporter)

Comment 29

7 years ago
I still have the same problem with the latest release of Minefield 4.0 b10 pre
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
What changeset ID in about:config?
(Reporter)

Comment 31

7 years ago
(In reply to comment #30)
> What changeset ID in about:config?

3d4620449437
That changeset doesn't have this patch. Try the next nightly build.
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago7 years ago
Resolution: --- → FIXED

Updated

7 years ago
Duplicate of this bug: 626090

Comment 34

6 years ago
On beta 9, I also see tabs disappear when I delete one.

Comment 35

6 years ago
I think Bug 626211 may be a dupe of this. This is how Twitter.com appears in FF4 B9: http://screencast.com/t/D88TCC1hTJme

Fixed in subsequent Minefield builds for me.

Updated

6 years ago
Duplicate of this bug: 626211
(Reporter)

Comment 37

6 years ago
(In reply to comment #32)
> That changeset doesn't have this patch. Try the next nightly build.

is the same also on build 20110117033243
What's the build ID in about:buildconfig?
(Reporter)

Comment 39

6 years ago
Now with 66addc5c30ca works very good!
Thanks to all!
Duplicate of this bug: 627043
No longer blocks: 625124
You need to log in before you can comment on or make changes to this bug.