Closed Bug 363757 Opened 18 years ago Closed 16 years ago

Resize widget not redrawn in some cases

Categories

(Core :: Widget: Cocoa, defect, P3)

Product:
Core
Component:
Widget: Cocoa
Platform:
All
macOS
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9.2a1

People

(Reporter: waynegwoods, Assigned: jaas)

References

Details

(Keywords: regression, Whiteboard: [fixed by bug 459319])

Attachments

(1 file, 1 obsolete file)

python script mentioned in patch
1.40 KB, text/plain
Details 
The window resize widget has been drawing a bit strangely in the tabbed browser.

1. In a fresh window (no tab bar), load a page, such as http://www.mozilla.org/
2. Hit cmd-t to create a new tab in the background.
3. The resize widget in the bottom right-hand corner should now be all white (it still functions, however).

Nothing that I've tried will redraw the widget in that particular window once it's vanished.

This isn't reproducible if the first tab is blank (though it does work if the loaded page is nothing except empty <html> tags).
It's also not reproducible if the tab bar already exists, or if the second tab created has actual content (say, if you cmd-click on a link in the first tab).

If you create the second tab while the first page is still loading, the widget doesn't seem to vanish, but it does noticeably "flicker".

The bug only exists from the 20061122 trunk nightly onwards, so I assume it's a Cairo issue.
Depends on: 364221
This bug does not seem to depend on bug 364221. AFAICS, this is about a redrawing error, and bug 364221 is performance related. Removing dep.
No longer depends on: 364221
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9+
While tracking this down I ran into the fix for bug 188927, which now lives in http://lxr.mozilla.org/seamonkey/source/toolkit/content/xul.css#344 -- removing that XP_MACOSX case causes no change to the widget redrawing problem, but it also causes no other change whatsoever.  Is that because I'm using the default theme?
Ok, looks like that's still needed; the OS itself draws the resize marks for us here, so we need to hide that widget.
So as far as I can tell, the OS is simply not drawing the resize widget in some cases, and I can't figure out what those cases are.  I thought it might try to "guess" whether there should be one drawn or not, based on the rest of the child views (looking for a scrollbar or something) but that doesn't seem to be it.

We might want to simply tell the OS to not draw that widget and just draw it ourselves.
Target Milestone: --- → mozilla1.9beta1
Target Milestone: mozilla1.9beta1 → mozilla1.9beta2
Assignee: vladimir → nobody
Target Milestone: mozilla1.9 M9 → ---
Target Milestone: --- → mozilla1.9 M10
Assignee: nobody → cbarrett
Target Milestone: mozilla1.9 M10 → mozilla1.9 M11
Priority: -- → P5
Target Milestone: mozilla1.9 M11 → ---
I can reproduce this, both with Pinstripe and Proto 0.8.1

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b3pre) Gecko/2007121204 Minefield/3.0b3pre
Attached patch WIP fix 0.5 (obsolete) — — Splinter Review 
This is a work in progress fix. It works except for the resize widget being one pixel too high up. I can't seem to get it to work right, but my knowledge of chrome CSS is poor, and I can't get DOMi to inspect chrome (??)
Here's the python script I was talking about. Works on my machine using Python 2.4.4 and PIL 1.1.6 from macports.

  python24 @2.4.4_1+darwin_8
  py-pil @1.1.6_0
Priority: P5 → P3
(In reply to comment #7)
> Created an attachment (id=294300) [details]
> WIP fix 0.5
> 
> This is a work in progress fix. It works except for the resize widget being one
> pixel too high up. I can't seem to get it to work right, but my knowledge of
> chrome CSS is poor, and I can't get DOMi to inspect chrome (??)
> 

The 1px too high up issue is probably because of the -moz-box-align/pack rules (global.css):

statusbarpanel {
  -moz-box-align: center;
  -moz-box-pack: center;
  padding: 0px;
  -moz-appearance: dialog;
}

You probably want "end" instead of center, you can do that just on the statusbarpanel that contains the resizer:

.statusbar-resizerpanel {
  -moz-box-align: end;
  -moz-box-pack: end;
}

It looks like the resizer itself would need some bottom padding/margin from the widget. The diagonal lines are drawn to the very bottom of the resizer widget, but on the right side it looks like there is some space at the end.

The resizer seems to have a fixed background color, wouldn't that be a problem if you have a statusbar with a different color? On Leopard, the background color seems to be transparent (Terminal window, for instance). 
> It looks like the resizer itself would need some bottom padding/margin from the
> widget. The diagonal lines are drawn to the very bottom of the resizer widget,
> but on the right side it looks like there is some space at the end.
> 

Making it 14x14 fixes it, of course.
Hmm, this won't work in windows without a statusbar.
Minusing this after talking to josh; it's really bad, but there are many more more bad things, unfortunately.
Flags: blocking1.9+ → blocking1.9-
Note that it looks like the resize widget is drawn if you have hidden the statusbar (uncheck "View --> Statusbar").
(In reply to comment #11)
> Hmm, this won't work in windows without a statusbar.

So, er, how is this going to fix bug 56488, then? :)

(In reply to comment #14)
> (In reply to comment #11)
> > Hmm, this won't work in windows without a statusbar.
> 
> So, er, how is this going to fix bug 56488, then? :)
> 

You have to ask Colin, but I think the ambition here was to fix bug 56488 as well. See for example bug 393866, comment #2 ;-).
Assignee: mozcbarrett → joshmoz
Maybe Marcus (who fixed bug 393866) have some ideas...
(In reply to comment #16)
> Maybe Marcus (who fixed bug 393866) have some ideas...

Erm, bug 56488.


(In reply to comment #4)
> So as far as I can tell, the OS is simply not drawing the resize widget in some
> cases, and I can't figure out what those cases are.

Just guessing: Maybe it only draws it after drawRect has been called with a rect that intersects with the resizer rect, and so it gets hidden whenever we draw outside the bounds of the dirty rect or independent of a drawRect call.
That's just a theory though; I'd have to do some testing.
See bug 448899 where that also happens within the Library. Opening the History container with a vertical scrollbar lets the resizer disappear. Opening another folder afterwards shows up the resizer. It is quiet good to reproduce.
Hardware: Macintosh → All
(In reply to comment #4)
> So as far as I can tell, the OS is simply not drawing the resize widget in some
> cases, and I can't figure out what those cases are.

It happens when drawRect is invoked synchronously (using displayIfNeeded in nsChildView::Update).

The patch in bug 459319 fixes this bug.
Summary: [Cairo] Resize widget not redrawn when tab bar created by opening blank tab in background → Resize widget not redrawn in some cases
Whiteboard: see bug 431169 for alternative STR
Fixed by bug 459319, I think.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
Attachment #294300 - Attachment is obsolete: true
Wayne, can you please check, if the problem is fixed for you by using a trunk build? Thanks.
Depends on: 459319
Whiteboard: see bug 431169 for alternative STR → [fixed by bug 459319]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: