Camino hangs and redraws when selecting while hidden

RESOLVED FIXED in Camino1.0

Status

--
major
RESOLVED FIXED
14 years ago
14 years ago

People

(Reporter: david.vanscott, Assigned: sfraser_bugs)

Tracking

({fixed1.8, perf, regression})

unspecified
Camino1.0
PowerPC
macOS
fixed1.8, perf, regression
Dependency tree / graph
Bug Flags:
camino0.9 -

Details

Attachments

(4 attachments, 2 obsolete attachments)

(Reporter)

Description

14 years ago
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.
works for me. what url do you have visible?
(Reporter)

Comment 2

14 years ago
(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.
what does sampler or shark show?
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?
Severity: normal → major
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Keywords: regression
Target Milestone: --- → Camino0.9

Comment 5

14 years ago
This is happening with 0.8.4 too.
(Assignee)

Comment 6

14 years ago
What does ThreadViewer say is it's doing during this time?
Keywords: perf

Comment 7

14 years ago
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.
(Reporter)

Comment 8

14 years ago
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.
(Assignee)

Comment 9

14 years ago
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.
Posted file report from shark
a report generated from a shark sample (the sample file itself is too big to
attach).
(Assignee)

Comment 11

14 years ago
Hrm, that shark report doesn't look quite right. I'd expect us to be in drawing
code.
(Reporter)

Comment 12

14 years ago
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

14 years ago
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.

Updated

14 years ago
Flags: camino0.9-
Target Milestone: Camino0.9 → Camino1.0
(Assignee)

Comment 14

14 years ago
Do people still see this?
(Reporter)

Comment 15

14 years ago
Yep, I still see this behavior whenever I hide and reshow Camino.
(Assignee)

Comment 16

14 years ago
Still need info.
(Reporter)

Comment 17

14 years ago
What kind of info?
(Assignee)

Comment 18

14 years ago
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.
(Reporter)

Comment 19

14 years ago
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.
(Assignee)

Comment 20

14 years ago
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?
(Reporter)

Comment 21

14 years ago
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.
(Assignee)

Comment 22

14 years ago
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.
my guess is that rendering pipeline optimizations in Tiger are causing this,
primarily because we have a NSQuickDrawView in the window.

Comment 24

14 years ago
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
(Reporter)

Comment 25

14 years ago
(Assignee)

Comment 26

14 years ago
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.
(Assignee)

Comment 27

14 years ago
(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.
Summary: Camino hangs and redraws when selecting while hidden. → Camino hangs and redraws when selecting while hidden
(Reporter)

Comment 28

14 years ago
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.
(Assignee)

Comment 29

14 years ago
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:.
Assignee: pinkerton → sfraser_bugs
Status: ASSIGNED → NEW
(Assignee)

Comment 30

14 years ago
Posted patch Patch (obsolete) — Splinter Review
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.
Attachment #195833 - Flags: review?(mark)

Comment 31

14 years ago
Comment on attachment 195833 [details] [diff] [review]
Patch

Put the whole setSuppressMakeKeyFront block including its comment in an #if 0,
and r=me.
Attachment #195833 - Flags: review?(mark) → review+
(Assignee)

Comment 32

14 years ago
Posted patch Better patch (obsolete) — Splinter Review
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.
Attachment #195833 - Attachment is obsolete: true
Attachment #195837 - Flags: superreview?(pinkerton)
Attachment #195837 - Flags: review?(mark)

Comment 33

14 years ago
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".
Attachment #195837 - Flags: review?(mark) → review+
(Assignee)

Comment 34

14 years ago
Comment on attachment 195837 [details] [diff] [review]
Better patch

This patch still needs work (causes crashes)
Attachment #195837 - Flags: superreview?(pinkerton)
(Assignee)

Comment 35

14 years ago
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.
Attachment #195837 - Attachment is obsolete: true
Attachment #197137 - Flags: review?(mark)

Comment 36

14 years ago
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.
Attachment #197137 - Flags: review?(mark) → review+
*** Bug 308878 has been marked as a duplicate of this bug. ***

Comment 38

14 years ago
(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. 
(Assignee)

Comment 39

14 years ago
(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.
(Assignee)

Comment 40

14 years ago
Fixed on trunk. I'll wait a few days before checking into the branch.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED

Comment 41

14 years ago
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
(Assignee)

Comment 42

14 years ago
Flash input seems to be FF also (bug 310626).
Did the patch that was checked in for this include the fix for bug 308878, or
does bug 308878 need to be reopened?
(Assignee)

Comment 44

14 years ago
I was assuming that, since the reporter said that my patch fixed it.
(Reporter)

Comment 45

14 years ago
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.
(Assignee)

Comment 46

14 years ago
(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?
(Assignee)

Comment 47

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

Updated

14 years ago
Blocks: 311049
(Assignee)

Comment 48

14 years ago
Landed on branch (along with fix for bug 311049).
Keywords: fixed1.8
(Assignee)

Updated

14 years ago
Blocks: 311683
(Assignee)

Comment 49

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

Comment 50

14 years ago
(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
You need to log in before you can comment on or make changes to this bug.