Closed Bug 18240 Opened 25 years ago Closed 25 years ago

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

Categories

(Core :: Layout, defect, P1)

PowerPC
Mac System 8.5
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: cpratt, Assigned: mikepinkerton)

References

Details

(Whiteboard: Fix in hand, waiting approval.)

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.
QA Contact: leger → elig
elig, perhaps you can forward this to the right person / put it in the right
category? Thanks!
Assignee: leger → elig
Assignee: elig → troy
Component: Browser-General → Layout
QA Contact: elig → petersen
petersen, can you check this out please.
Assignee: troy → beard
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.
*** Bug 18533 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Target Milestone: M14
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.
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.)
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?
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.
Assignee: beard → pinkerton
Status: ASSIGNED → NEW
adding pierre per his request.
The editor bug I'm referring to is bug #13438.
Status: NEW → ASSIGNED
accepting
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.
Priority: P3 → P1
upgrading to p1. this happens for me now even w/out about:blank being the startup
page.
Whiteboard: Fix in hand, waiting approval.
Whiteboard says it all, fix in hand. will send out mail with diffs. god this one
sucked.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
checked in. all is good now.
Problem has been fixed in the Jan 20 th build.
Status: RESOLVED → VERIFIED
Blocks: 24854
You need to log in before you can comment on or make changes to this bug.