18240 - When Mac has about:blank as startup page, bad window drawn

Status: VERIFIED FIXED

(Core :: Layout, defect, P1)

Description

[cpratt]

Build ID: 1999110808, others
Platform: Mac OS only; not reproducible on Linux or Win32

To reproduce:
- Launch the browser
- Select Edit | Preferences
- Click on Navigator
- Set the home page to 'about:blank'
- Quit and relaunch the browser

Result: The page drawn by apprunner is missing parts of what you would expect to
see there.

Expected result: Everything is drawn correctly.

If you resize or hide/show the window, it displays correctly.

Comment 1

[cpratt]

elig, perhaps you can forward this to the right person / put it in the right
category? Thanks!

Comment 2

[leger]

petersen, can you check this out please.

Comment 3

[troy]

If it's a Mac only bug, then it cannot be a layout bug. We have no Mac specific
code anywhere in layout...

Patrick, maybe you know how to assign this to. Thanks.

Comment 4

[Alec Flett]

*** Bug 18533 has been marked as a duplicate of this bug. ***

Comment 5

[Patrick C. Beard]

Missing a gray background is what I see. Anything else? I'd guess we aren't
generating the appropriate paint events. If I create a second window, it is
drawn correctly with the gray background.

Comment 6

[Patrick C. Beard]

One issue to note:  I have debugging code that blinks the areas that are being
invalidated by calls to nsWindow::Invalidate()/InvalidateRegion(), and I see the
full browser content area invalidated at leaste once. One possibility
is that when the window is first created the content that draws the gray
background isn't doing so. Perhaps it isn't ready when the paint events
are initially delivered. (I'm just guessing here.)

Comment 7

[Patrick C. Beard]

Here's the problem. When nsCSSRendering::PaintBackground() gets called by XXX,
the clipRgn of the current Quickdraw port was set to
(t, l, b, r) = (0, 0, 1, 744). I set some breakpoints in GFX to see how the
clipRgn is getting set, and was surprised to see that
PresShell::ProcessReflowCommands() is creating and destroying rendering contexts,
and this is having the side-effect of setting the clipping region in the
still hidden window to (1x1) bounds. Why are rendering contexts being created
here? And, why aren't we restoring the clipRgn correctly?

Comment 8

[Patrick C. Beard]

The problem is caused by an incorrect notion of "visibility" of the content
area's widget. Changing the following code in nsWindow.cpp:

     case NS_NATIVE_REGION:
-//   	retVal = (void*)mWindowRegion;
+    	CalcWindowRegions();
+//	   	retVal = (void*)mWindowRegion;
     	retVal = (void*)mVisRegion;
     	break;

makes the problem go away, but is obviously too brute forcish a solution. The
reason this works is that each time nsRenderingContext::Init() is called with a
widget, it calls nsIWidget::GetNativeData(NS_NATIVE_REGION) to get the visible
region of the widget in question. When the program first starts up, the visible
region of the content area widget is incorrect, so we under update the area.

This is probably the problem with the editor when it starts up with empty content
as well.

Comment 9

[Mike Pinkerton (not reading bugmail)]

adding pierre per his request.

Comment 10

[Patrick C. Beard]

The editor bug I'm referring to is bug #13438.

Comment 11

[Mike Pinkerton (not reading bugmail)]

accepting

Comment 12

[Mike Pinkerton (not reading bugmail)]

Patrick, i have some data on this, varying values of the visRgn before and after
the call to CalcWindowRegions() and I just don't have a clue what is going on.
The time time you're in MV can you come by my cube and give me some context on
what is going on? It would help me a lot, I think! Thanks.

Comment 13

[Mike Pinkerton (not reading bugmail)]

upgrading to p1. this happens for me now even w/out about:blank being the startup
page.

Comment 14

[Mike Pinkerton (not reading bugmail)]

Whiteboard says it all, fix in hand. will send out mail with diffs. god this one
sucked.

Comment 15

[Mike Pinkerton (not reading bugmail)]

checked in. all is good now.

Comment 16

[Chris Petersen]

Problem has been fixed in the Jan 20 th build.

Comment 17

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/5aa2d1a7b3cb
[fenix] For https://github.com/mozilla-mobile/fenix/issues/18240 - Add a Credit Card preference screen (https://github.com/mozilla-mobile/fenix/pull/18410)
https://hg.mozilla.org/releases/mozilla-beta/rev/f6dbd06741b0
[fenix] For https://github.com/mozilla-mobile/fenix/issues/18240: Adjust preference screen to fit UX specs.