71.04 KB, image/png
13.81 KB, text/plain
23.41 KB, application/rtf
35.91 KB, patch
|Details | Diff | Splinter Review|
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?
(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
Target Milestone: --- → Camino0.9
This is happening with 0.8.4 too.
What does ThreadViewer say is it's doing during this time?
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.
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.
a report generated from a shark sample (the sample file itself is too big to attach).
Hrm, that shark report doesn't look quite right. I'd expect us to be in drawing code.
I ran the Time Profile report with Shark and that's what I got. What should I have run to help you guys best?
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.
Do people still see this?
Yep, I still see this behavior whenever I hide and reshow Camino.
Still need info.
What kind of info?
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.
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.
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?
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.
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.
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
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.
(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
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.
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
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 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+
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 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+
Comment on attachment 195837 [details] [diff] [review] Better patch This patch still needs work (causes crashes)
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 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. ***
(In reply to comment #35) > Created an attachment (id=197137)  > 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.
(In reply to comment #38) > (In reply to comment #35) > > Created an attachment (id=197137)   > > 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. Yeah, this patch didn't contain some stuff in camino/ (the #if 0 in BrowserWindowController). We still need those parts.
Fixed on trunk. I'll wait a few days before checking into the branch.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
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
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?
I was assuming that, since the reporter said that my patch fixed it.
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.
(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?
Actually I can reproduce it, when focus is in the URL bar. This also occurs in 1.0a1, and I filed as bug 311084.
Landed on branch (along with fix for bug 311049).
This caused bug 311683, and the patch there undoes this patch, and uses my second suggestion from comment 30 instead.
(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.