315576 - [BEOS] Menubar/Toolbar/bookmarks toolbar repaint incorrectly after popup windows close.

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[Doug Shelton]

User-Agent:       Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.9a1) Gecko/20051105 Firefox/1.6a1
Build Identifier: Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.9a1) Gecko/20051105 Firefox/1.6a1

Recently introduced method in nsViewBeOS to reduce unneeded Draws results in improper repaint.  See attached jpg for picture.  Tested by changing

	if (paintregion.CountRects() == 0 || !paintregion.Frame().IsValid() || !fJustValidated)

to 
	if (paintregion.CountRects() == 0 || !paintregion.Frame().IsValid() /*|| !fJustValidated*/)

in nsViewBeOS::Draw.


Reproducible: Always

Steps to Reproduce:
1.start browser
2.go to url above
3.run benchJS
4.wait for step 2 (pop up windows) to complete


Actual Results:  
if any part of menubar, toolbar or bookmark toolbar is obscured by the popups, they'll be corrupted after the popups close.

Expected Results:  
windows should close and bars should return to normal.

Comment 1

[Doug Shelton]

Attachment: view of corrupted display

attachment is .png, not .jpg as mentioned above.

Comment 2

[Doug Shelton]

adding block of 311032 tracking bug

Comment 3

[Sergei Dolgov]

i think i will fix this in previous bug about scrolling

Comment 4

[Sergei Dolgov]

tqh, what do you think if it may be related to our Destroy() code?

Comment 5

[tqh]

I'm not going to rule it out, but don't think it's very likely.

Comment 6

[Sergei Dolgov]

tqh,
look by the way here:
http://www.livejournal.com/community/bezilla/144925.html

Comment 7

[Sergei Dolgov]

It seems like here is happening what i'm was afraid about for long time.
Our tricks/hacks with event priorities in nsAppShell may broke normal order of events.
Probability isn't too high, but now it happened on modern x64 processor.

As natural solution, looks like 'natv' events must be set to lower priority queue .
Or, as hack, we need additional priority level for ONPAINT, as i don't wish to put it at same level as user-triggered events (keyboard, mouse click, move, wheel)

Comment 8

[tqh]

Also it might be good to set nsAppshell's event-thread to have higher priority than ordinary windows so that it always can process events faster than windows can create new events. Right now they are at same priority.

Comment 9

[Doug Shelton]

Attachment: patch to nsAppShell.cpp fixes problem

solution changes priority of native event queue PLEvents.

Comment 10

[tqh]

Comment on attachment 202413 [details] [diff] [review]
patch to nsAppShell.cpp fixes problem

r=[e-mail]

Comment 11

[Sergei Dolgov]

Checking in mozilla/widget/src/beos/nsAppShell.cpp;
/cvsroot/mozilla/widget/src/beos/nsAppShell.cpp,v  <--  nsAppShell.cpp
new revision: 1.30; previous revision: 1.29
done 

Comment 12

[Sergei Dolgov]

closing for now.
though, it will be interesting to test our appshell at some quad x86-64 5 GHz machines in near future:)

Comment 13

[Niels Reedijk]

Comment on attachment 202413 [details] [diff] [review]
patch to nsAppShell.cpp fixes problem

Requesting permission for the MOZILLA_1_8_BRANCH.

This is a BeOS-only change and does not affect any other platform.

Comment 14

[Sergei Dolgov]

Checking in mozilla/widget/src/beos/nsAppShell.cpp;
/cvsroot/mozilla/widget/src/beos/nsAppShell.cpp,v  <--  nsAppShell.cpp
new revision: 1.29.8.1; previous revision: 1.29
done