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)

Product:
Core
Component:
Widget: Cocoa
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9beta2

People

(Reporter: moco, Assigned: smichaud)

References

Details

Attachments

(2 files)

screen shot of the bug, bugzilla page has loaded, notice the title of the tab is "Loading..."
229.16 KB, image/jpeg
Details
screen shot after I resize, content shows up and tab title is correct
110.95 KB, image/jpeg
Details 
[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.)
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.
I haven't experienced this bug.
> 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.
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.
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
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.
> 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.
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.
note, when in this state, the title of the window doesn't update either!
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
showed this to stuart, and he agrees that it's blocking.
Flags: blocking1.9? → blocking1.9+
Whiteboard: [blocking1.9a1+]
seth do you still see this?
Flags: blocking1.9+ → blocking1.9?
I saw this a few times over the last week.
> 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?
I've never seen it; whether that's the result of using a dialup connection, or coincidence, I don't know.
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: 17 years ago
Resolution: --- → WORKSFORME
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 → ---
note, when I see this bug I see bug #354768 as well
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
I wonder if there is any relationship with this and bug 368336
Given our new debug info marking this as blocking. We need to investigate those leads.
Flags: blocking1.9? → blocking1.9+
Target Milestone: --- → mozilla1.9beta1
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.
Target Milestone: mozilla1.9beta1 → mozilla1.9beta2
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.
Now that bug 354768 is fixed, does anybody see this any more?
Target Milestone: mozilla1.9 M9 → ---
Target Milestone: --- → mozilla1.9 M10
Closing this out again, go ahead and reopen if anyone sees it again.
Whiteboard: [blocking1.9a1+]
Status: REOPENED → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee: joshmoz → smichaud
Status: REOPENED → NEW
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.

Attachment

General

Creator:
Created:
Updated:
Size: