297343 - Camino hangs and redraws when selecting while hidden

Status: RESOLVED FIXED

(Camino Graveyard :: General, defect)

Description

[David VanScott]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050609 Camino/0.9a1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050609 Camino/0.9a1

When Camino is hidden in Tiger (10.4.1) and I select it to bring it back up, the
entire window is white and takes 2-5 seconds to completely redraw. 
Additionally, during that time, the CPU Usage from Camino jumps from under 1% to
almost 25%, then settles back to normal after redrawing.

Reproducible: Always

Steps to Reproduce:
1. Hide Camino
2. Select it from the dock or through Cmd+Tab

Actual Results:  
The window goes white and takes several seconds to redraw.

Expected Results:  
Coming from hiding, there should be no wait and no redrawing.  It should be instant.

Comment 1

[Mike Pinkerton (not reading bugmail)]

works for me. what url do you have visible?

Comment 2

[David VanScott]

(In reply to comment #1)
> works for me. what url do you have visible?

It never matters what URL I have, it does it every time.  I don't have any
special setup on my laptop nor do I have any unique software running.  I know
that several people on the MozillaZine message boards have the same problem.

Comment 3

[Mike Pinkerton (not reading bugmail)]

what does sampler or shark show?

Comment 4

[Mike Pinkerton (not reading bugmail)]

i see this on my tibook with 2005060908. it doesn't "hang" per-se, but the
entire window is white (no chrome) and then repaints correctly.

can someone go back in the nightlies and figure out when this broke?

Comment 5

[Echidnae]

This is happening with 0.8.4 too.

Comment 6

[Simon Fraser [no longer active]]

What does ThreadViewer say is it's doing during this time?

Comment 7

[Ulrik Sverdrup]

Attachment: Screenshot from ThreadViewer

I see this strange behaviour but I don't have to wait 2-3 secs for the redraw,
it just repaints in 0.5 secs.

Camino does something wrong, though, as there is no other application that's
painting the windows white upon unhiding.

Comment 8

[David VanScott]

I had the opportunity to test this on a 17" iMac G5 with 10.4.1 installed and
like was said previously, it doesn't take 2-3 seconds, only about .5, but it
still is white and needs to redraw.

Comment 9

[Simon Fraser [no longer active]]

Some observations:
1. Using QuartzDebug, I see that Camino draws the entire window twice on unhide.
   Other applications only draw it once. We should look for the cause of the
   second redraw (maybe gecko doing an invalidate on focus/activate changes).

2. There is a much longer delay between the two redraws if the caret is blinking
   in a text field.

The second observation suggests that this issue is affected by the port flush
that is called from the caret code.

Comment 10

[Mike Pinkerton (not reading bugmail)]

Attachment: report from shark

a report generated from a shark sample (the sample file itself is too big to
attach).

Comment 11

[Simon Fraser [no longer active]]

Hrm, that shark report doesn't look quite right. I'd expect us to be in drawing
code.

Comment 12

[David VanScott]

I ran the Time Profile report with Shark and that's what I got.  What should I
have run to help you guys best?

Comment 13

[Josh Aas]

This sucks for some people, but I think we should bump it from the 0.9 list so
we can actually ship 0.9 someday... If neither Mike nor Simon objects, I'll bump
this to 1.0 tomorrow.

Comment 14

[Simon Fraser [no longer active]]

Do people still see this?

Comment 15

[David VanScott]

Yep, I still see this behavior whenever I hide and reshow Camino.

Comment 16

[Simon Fraser [no longer active]]

Still need info.

Comment 17

[David VanScott]

What kind of info?

Comment 18

[Simon Fraser [no longer active]]

Better profiling data, for one. Also, why this appears to be so much worse for
some people. Does it depend on the number of tabs in the window? Whether the
window contains plugins (like Java)? How much memory the machine has, etc etc.

Comment 19

[David VanScott]

Well, I'm not sure about profiling data.  If someone lets me know what to do,
I'd be more than happy to gather this data.  Personally, it doesn't matter how
many tabs I have open, it redraws every time that I bring it back from hiding. 
It will do this whether the open tabs have Java apps running in them or not. 
Right now I'm running 1.25GB of RAM on a 1.33Ghz PowerBook.  It seems that less
RAM accenuates the hang, at least from what I've seen.  I have yet to test
Camino on a machine that it doesn't do this, official build or optimized build.

Comment 20

[Simon Fraser [no longer active]]

So, do you still see a significant delay when activating Camino under these
conditions?
1. Few other applications running
2. Freshly launched Camino showing one simple web page
3. Java disabled

Does this behaviour pesist if you reboot the machine and then test?

Comment 21

[David VanScott]

I've tested Camino under a variety of situations.  This bug happens whether
Camino is the only program running, or one of several programs running.  I can
quit Camino and just have 1 tab with www.caminobrowser.org/start/, hide it, and
still have the redraw problem.  I tried disabling Java, but it still redrew. 
And it acts the same if I reboot my machine.

Comment 22

[Simon Fraser [no longer active]]

David: here's how to get some data:
Run Camino, and hide it (in preparate for showing the bug)
Run Terminal, and type (but don't press Return yet!)
  sample Camino 5 5
Now quickly hit Return to start sampling, then click on Camino in the dock to
bring it to the front (when, presumably, it will hang for 2-5 seconds).
After 5 seconds is up, sample will say something like:
  Sample analysis of process 839 written to file /tmp/Camino_839.sample.txt
Please attach that "Camino_NNN.sample.txt" file to this bug.

Comment 23

[Mike Pinkerton (not reading bugmail)]

my guess is that rendering pipeline optimizations in Tiger are causing this,
primarily because we have a NSQuickDrawView in the window.

Comment 24

[JK]

Som info: if the text cursor (caret) is in the toolbar (URL or search bar) there
is no white page when Camino is unhide. But if the caret is in a text box inside
the content area, sometimes you see the blank page and sometimes you don't. If
there is no cursor blinking, you always get the white page and then the redraw.

PS1 -> it doesn't matter the actual page content and number of opened tabs.
PS2 -> it does happen in 0.8.4 official build too as well as nighlies.
PS3 -> it's Tiger's only (tested on an iMac G3 with OS X 10.3.9).

I hope this helps. Cheers.
JK

Comment 25

[David VanScott]

Attachment: Profiling Data from Camino

Comment 26

[Simon Fraser [no longer active]]

David: do you have any non-standard items in your menu bar?
Also, please try tomorrow's build (9/13) as I sped up some window drawing
operations.

Comment 27

[Simon Fraser [no longer active]]

(In reply to comment #24)
> Som info: if the text cursor (caret) is in the toolbar (URL or search bar) there
> is no white page when Camino is unhide. But if the caret is in a text box inside
> the content area, sometimes you see the blank page and sometimes you don't. If
> there is no cursor blinking, you always get the white page and then the redraw.

Aha! This is QDFlushPortBuffer stuff then.

Comment 28

[David VanScott]

I customized the toolbar a little bit, but nothing beyond the standard options
available.  I'll make sure to give tomorrow's build a whirl and see how things are.

Comment 29

[Simon Fraser [no longer active]]

I see what's happening now. It's basically re-entrant calls to
makeKeyAndOrderFront:, which cause us to show the window before the contents
have redrawn. This only happens if the focus is in the content area, not in the
URL bar.

There two places that cause us to call makeKeyAndOrderFront: from a
windowDidBecomeKey: call, and we have to fix both to avoid the
too-early-window-display. One is from [BrowserWindowController
windowDidBecomeKey:], and the other is in widget, from [ChildView
viewsWindowDidBecomeKey]. Both call APIs that cause Gecko to do focus work,
which end up calling back to CHBrowserListener::SetFocus(), which calls
-makeKeyAndOrderFront:.

Comment 30

[Simon Fraser [no longer active]]

Attachment: Patch

This patch fixes the bug by delaying the call that sends the focus and activate
events into Gecko until the next event loop cycle, in ChildView. This means
that when Camino's CHBrowserListener::SetFocus() gets called as a result of
those events, [window isVisible] and [NSApp keyWindow] are set up correctly, so
we short-circuit and avoid the troublesome call to -makeKeyAndOrderFront:

The alternative is to have the widget code call -setSuppressMakeKeyFront on the
window, which seems ickier.

Comment 31

[Mark Mentovai]

Comment on attachment 195833 [details] [diff] [review]
Patch

Put the whole setSuppressMakeKeyFront block including its comment in an #if 0,
and r=me.

Comment 32

[Simon Fraser [no longer active]]

Attachment: Better patch

This patch is like the last, but it fixes -viewsWindowDidResignKey to send a
NS_DEACTIVATE as well as a NS_LOSTFOCUS event, so that we can then remove the
setBrowserActive:NO call. This makes things symmetrical.

I think this is a bit risky to take for 1.0a1. We can land it after 1.0a1
ships.

Comment 33

[Mark Mentovai]

Comment on attachment 195837 [details] [diff] [review]
Better patch

Looks good.  Three congruity nits:

+- (void)sendUnfocusEvent

sendUnfocusDeactivateEvent or sendDeactivateUnfocusEvent?

   nsFocusEvent event(PR_TRUE, NS_LOSTFOCUS, mGeckoChild);

focusEvent, as it's called in sendFocusActivateEvent?

in -windowDidResignKey:

+  // on window activation, so no need to do this here:

in this method, "on window deactivation".

Comment 34

[Simon Fraser [no longer active]]

Comment on attachment 195837 [details] [diff] [review]
Better patch

This patch still needs work (causes crashes)

Comment 35

[Simon Fraser [no longer active]]

Attachment: Patch: fix and warning cleanup

This patch fixes crashes that were caused by delayed focus/unfocus calls coming
after the widget has been destroyed. It also makes the nsChildView's mView more
strongly typed, and fixes almost all the warnings.

Comment 36

[Mark Mentovai]

Comment on attachment 197137 [details] [diff] [review]
Patch: fix and warning cleanup

This is OK, with the change to BWC.

While you're cleaning up, remove WIDGET_SET_CLASSNAME nsCocoaWindow.mm.

Also, the second event in sendDeactivateEvent should be called focusEvent.

Looks like this will stave off a few other potential crashes.

Comment 37

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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

Comment 38

[Hiro]

(In reply to comment #35)
> Created an attachment (id=197137) [edit]
> Patch: fix and warning cleanup

In this patch, the problem of Bug 308878 did not fix...
In attachment 195837 [details] [diff] [review], Bug 308878 did fix. 

Comment 39

[Simon Fraser [no longer active]]

(In reply to comment #38)
> (In reply to comment #35)
> > Created an attachment (id=197137) [edit] [edit]
> > Patch: fix and warning cleanup
> 
> In this patch, the problem of Bug 308878 did not fix...
> In attachment 195837 [details] [diff] [review] [edit], Bug 308878 did fix. 

Yeah, this patch didn't contain some stuff in camino/ (the #if 0 in
BrowserWindowController). We still need those parts.

Comment 40

[Simon Fraser [no longer active]]

Fixed on trunk. I'll wait a few days before checking into the branch.

Comment 41

[JK]

I am having a problem here with focus for text entry in Flash content. Java
content seems to work fine. Using Flash 8.0 r22.
Common text entry works weirdly: sometime I have to go to another app and go
back to Camino for the text cursor to appear or wait a while for it to appear.

Cheers

Comment 42

[Simon Fraser [no longer active]]

Flash input seems to be FF also (bug 310626).

Comment 43

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Did the patch that was checked in for this include the fix for bug 308878, or
does bug 308878 need to be reopened?

Comment 44

[Simon Fraser [no longer active]]

I was assuming that, since the reporter said that my patch fixed it.

Comment 45

[David VanScott]

It appears that the patch used to fix this bug has had the side effect of 
stopping the cursor from becoming the hand cursor when mousing over links.  It 
can be recreated by hiding Camino, unhiding, and trying to click on links in 
the current tab.

Comment 46

[Simon Fraser [no longer active]]

(In reply to comment #45)
> It appears that the patch used to fix this bug has had the side effect of 
> stopping the cursor from becoming the hand cursor when mousing over links.  It 
> can be recreated by hiding Camino, unhiding, and trying to click on links in 
> the current tab.

I can't reproduce this in my dev build. What build were you seeing it in?

Comment 47

[Simon Fraser [no longer active]]

Actually I can reproduce it, when focus is in the URL bar. This also occurs in
1.0a1, and I filed as bug 311084.

Comment 48

[Simon Fraser [no longer active]]

Landed on branch (along with fix for bug 311049).

Comment 49

[Simon Fraser [no longer active]]

This caused bug 311683, and the patch there undoes this patch, and uses my
second suggestion from comment 30 instead.

Comment 50

[JK]

(In reply to comment #46)
> (In reply to comment #45)
> > It appears that the patch used to fix this bug has had the side effect of 
> > stopping the cursor from becoming the hand cursor when mousing over links.  It 
> > can be recreated by hiding Camino, unhiding, and trying to click on links in 
> > the current tab.
> 
> I can't reproduce this in my dev build. What build were you seeing it in?

Maybe it's a Tiger issue. Please take a look at https://bugzilla.mozilla.org/show_bug.cgi?id=296228