[cocoa] frequently, page doesn't show / repaint, I have to switch between tabs

RESOLVED FIXED in mozilla1.9beta2

Status

()

Core
Widget: Cocoa
--
major
RESOLVED FIXED
12 years ago
11 years ago

People

(Reporter: (not reading, please use seth@sspitzer.org instead), Assigned: smichaud)

Tracking

Trunk
mozilla1.9beta2
x86
Mac OS X
Points:
---
Bug Flags:
blocking1.9 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

[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

12 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

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

Comment 6

12 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

12 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.
> 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.
Created attachment 246165 [details]
screen shot of the bug, bugzilla page has loaded, notice the title of the tab is "Loading..."
Created attachment 246166 [details]
screen shot after I resize, content shows up and tab title is correct
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.

Updated

12 years ago
Flags: blocking1.9? → blocking1.9+
Whiteboard: [blocking1.9a1+]

Comment 15

11 years ago
seth do you still see this?
Flags: blocking1.9+ → blocking1.9?

Comment 16

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

Comment 19

11 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
Last Resolved: 11 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

Comment 26

11 years ago
Given our new debug info marking this as blocking. We need to investigate those leads.
Flags: blocking1.9? → blocking1.9+

Updated

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

Updated

11 years ago
Target Milestone: mozilla1.9beta1 → mozilla1.9beta2

Comment 29

11 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

11 years ago
Now that bug 354768 is fixed, does anybody see this any more?

Updated

11 years ago
Target Milestone: mozilla1.9 M9 → ---

Updated

11 years ago
Target Milestone: --- → mozilla1.9 M10

Comment 31

11 years ago
Closing this out again, go ahead and reopen if anyone sees it again.
Whiteboard: [blocking1.9a1+]

Updated

11 years ago
Status: REOPENED → RESOLVED
Last Resolved: 11 years ago11 years ago
Resolution: --- → FIXED

Updated

11 years ago
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Updated

11 years ago
Assignee: joshmoz → smichaud
Status: REOPENED → NEW

Updated

11 years ago
Status: NEW → RESOLVED
Last Resolved: 11 years ago11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.