Closed
Bug 360032
Opened 18 years ago
Closed 17 years ago
[cocoa] frequently, page doesn't show / repaint, I have to switch between tabs
Categories
(Core :: Widget: Cocoa, defect)
Tracking
()
RESOLVED
FIXED
mozilla1.9beta2
People
(Reporter: moco, Assigned: smichaud)
References
Details
Attachments
(2 files)
[cocoa] occasionally, page doesn't show / repaint, I have to switch between tabs
josh, my apoloigies on not having good steps to reproduce or details yet, but I have seen been seeing this.
I thought I logged a bug about it, but I could not find it.
starting this bug, and when I see it next I'll add more comments.
Seth, does resizing the window also "fix" it for you?
If so, it's potentially something we've seen in Camino (it's actually a very annoying regression sometime this summer on the branch as well as trunk) - bug 350331 comment 1-5. So far we've not had much luck figuring out when it happened or, as you say, solid steps to repro.
(Note that bug is overloaded with a separate widget/mac drag-drop regression mentioned by pink in bug 350331 comment 6. Ew.)
Comment 2•18 years ago
|
||
I haven't used a cocoa Minefield build often, but on my Reflow-branch builds (build with: ac_add_options --enable-default-toolkit=cocoa), I see the problem regularly. Running on 10.4.8 ppc.
Resizing the window (as on Camino, see bug 350331) always fixes it.
As with Camino, no consistent steps to repro, except perhaps one: if I access an Apache directory listing on my development server here, and click a link there, more often than not the page loads but doesn't display/paint.
Comment 3•18 years ago
|
||
I haven't experienced this bug.
Reporter | ||
Comment 4•18 years ago
|
||
> Seth, does resizing the window also "fix" it for you?
smokey, the next time it happens, I'll try that and report back here here.
phillipe, jesse, et al: thanks for the comments. I think there is a real bug here.
Reporter | ||
Updated•18 years ago
|
Flags: blocking1.9?
Note that cairo-cocoa uses a different path (and handles drawRect directly in the ChildView code), so this may be something that was in the old paint implementation that's used for Carbon only.
Comment 6•18 years ago
|
||
This is a very significant bug. I see it all the time, when using the trunk build for daily browsing.
For example, I just went to www.m-w.com to look up the definition of a word. The statusbar said "Waiting for reply..." for a long time, and I became suspicious (the content area still hadn't updated to the new page).
I resize the window, and it had all finished loading, probably a good while ago too. So this seems to affect not only the content area, but also the other views (e.g statusbar).
Severity: normal → major
Comment 7•18 years ago
|
||
It seems that once it has started happening, the browser goes into a state where it always happens. At least for me. The only way to get back to normal is to restart.
Reporter | ||
Comment 8•18 years ago
|
||
> It seems that once it has started happening, the browser goes into a state
> where it always happens. At least for me.
that's what happens to me, too.
I've recently switched to cocoa-cairo, and I'm still waiting for it to happen again.
Reporter | ||
Comment 9•18 years ago
|
||
I'm seeing this right now with my cocoa cairo build from Mon Nov 20 13:06:25 PST 2006.
resizing the window does cause things to paint, but it's not just the content that isn't painting, but some chrome as well. for example, the title of the page in the tab also repaints when I resize.
I'll attach a few screen shots.
Reporter | ||
Comment 10•18 years ago
|
||
Reporter | ||
Comment 11•18 years ago
|
||
Reporter | ||
Comment 12•18 years ago
|
||
note, when in this state, the title of the window doesn't update either!
Reporter | ||
Comment 13•18 years ago
|
||
I seem to be hitting this all the time, and so I think it deserves blocking consideration for 1.9a1.
Summary: [cocoa] occasionally, page doesn't show / repaint, I have to switch between tabs → [cocoa] frequently, page doesn't show / repaint, I have to switch between tabs
Reporter | ||
Comment 14•18 years ago
|
||
showed this to stuart, and he agrees that it's blocking.
Updated•18 years ago
|
Flags: blocking1.9? → blocking1.9+
Whiteboard: [blocking1.9a1+]
Comment 16•18 years ago
|
||
I saw this a few times over the last week.
Reporter | ||
Comment 17•18 years ago
|
||
> seth do you still see this?
sorry, I haven't been using my mac trunk very much lately.
Perhaps other hard-core mac firefox trunk users can comment?
Comment 18•18 years ago
|
||
I've never seen it; whether that's the result of using a dialup connection, or coincidence, I don't know.
Comment 19•18 years ago
|
||
I still see this in the latest trunk if I minimize the window and bring it back from the dock. In order to get it to work again I need to start a new window or restart firefox.
(In reply to comment #19)
> I still see this in the latest trunk if I minimize the window and bring it back
> from the dock. In order to get it to work again I need to start a new window or
> restart firefox.
That's bug 368336.
-> worksforme, if anyone sees this again please reopen
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 22•18 years ago
|
||
re-opening. just saw this today with my own trunk debug build:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a5pre) Gecko/20070502 Minefield/3.0a5pre
more details (and a console log) coming soon...
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Reporter | ||
Comment 23•18 years ago
|
||
note, when I see this bug I see bug #354768 as well
Reporter | ||
Comment 24•18 years ago
|
||
some more new info:
when I see this bug, the title of the browser window does not update when I switch tabs. only when I resize the entire window does it get updated.
in my console I'm seeing:
WARNING: NS_ENSURE_TRUE(aPresContext->Document()->GetWindow()) failed: file /Users/sspitzer/Desktop/trunk-no-places/mozilla/content/events/src/nsIMEStateManager.cpp, line 175
###!!! ASSERTION: win is null. this happens [often on xlib builds]. see bug #79213: 'Error', file /Users/sspitzer/Desktop/trunk-no-places/mozilla/content/events/src/nsEventStateManager.cpp, line 986
Comment 25•18 years ago
|
||
I wonder if there is any relationship with this and bug 368336
Comment 26•18 years ago
|
||
Given our new debug info marking this as blocking. We need to investigate those leads.
Flags: blocking1.9? → blocking1.9+
I see this bug constantly. In debug and opt builds. I'm not using tabs.
I see those errors from comment #24.
One thing I've noticed, I think, is that when a window gets into this state, the only way to get focus back is to bring another window to the front and then click in the bad window *in a text field* to raise it. Clicking on normal parts of the window will raise it but doesn't ever seem to get it out of the bad state.
Comment 29•17 years ago
|
||
Don't know if this is helpful, but I'm getting a similar behaviour on Kubuntu Feisty Linux as of 2.0.0.6. (wasn't there in 2.0.0.5).
Changing tabs is not enough to get it to repaint. Refreshing the page *sometimes* works, resizing window always fixes it, minimising/restoring does *not*.
I didn't find a similar bug in the Linux area of bugzilla, but please let me know if there is one. (otherwise I'll post over there)
Also, it only happens in one of two profiles that I use. I have about 10 extensions, but the behaviour persists even with them all disabled.
Comment 30•17 years ago
|
||
Now that bug 354768 is fixed, does anybody see this any more?
Updated•17 years ago
|
Target Milestone: mozilla1.9 M9 → ---
Comment 31•17 years ago
|
||
Closing this out again, go ahead and reopen if anyone sees it again.
Whiteboard: [blocking1.9a1+]
Status: REOPENED → RESOLVED
Closed: 18 years ago → 17 years ago
Resolution: --- → FIXED
Status: NEW → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•