90489 - Window resize handle (grow box) covers offline indicator

Status: VERIFIED WONTFIX

(SeaMonkey :: Themes, defect)

Description

[Mitch Green]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2+)
Gecko/20010709 Netscape6/6.1b1
BuildID:    

The window resize handle in the lower-right corner of the Macintosh UI intrudes
upon the security padlock and network connection icons.  The default position
for these icons needs to be moved a few pixels to the "left".

Reproducible: Always
Steps to Reproduce:
1. run on a mac
2. look at lower right corner of window, especially on mail compose and mail
messages windows.
3.

Actual Results:  obscured icons

Expected Results:  unobscured icons

The problem is "theme" independent.  I tried with Classic, Mozilla-modern and
Toy Factory PR1 without any difference in behavior.

Comment 1

[Matthew T (active 1999-2002)]

Yes, this is a problem in message composition and Composer at least. It will be 
a problem on Windows too, once the sizing grippy is added to resizable windows 
on that platform.

Someone should file separate bugs for each faulty window, and make them block 
this one. The appropriate fix is to add a 16*16 <box> to the bottom right 
corner of these windows -- that way theme authors don't have to each take care 
of it.

Comment 2

[Blake Ross]

I don't believe that's the right fix. I believe the right fix is that <window/>s
should get this box for free, without each file having to specify it.

Comment 3

[Mike Pinkerton (not reading bugmail)]

there's really no way to solve this in the general case. take, for example, the 
view-source window. If we made it such that there was an area blocked out where 
nothing could be laid out there, we'd end up with a content area inset by 16px on 
the bottom and right and all of that space empty.

Perhaps there's something that can be done for status bars in general, but that 
should be done in the status bar code not at the window level. I think it 
involves a case-by-case analysis and that any sweeping toolkit change would not 
be correct for all cases.

who owns the status bar xbl? Is there something that every status bar inherits 
from?

Comment 4

[timeless]

i think if we put code into statusbar, and both scroll bars we'd be pretty much 
covered.

the one case left is a page that fits perfectly into a view source window that 
has no scrollbars or sizer but for which one or two chars would be covered by 
the grippy.  I think that's acceptable, if someone needs those characters they 
can resize the window (or [drag] select them).

Comment 5

[grylchan]

Another bug (possible dupe?)that is related, bug 83222

Comment 6

[sairuh (rarely reading bugmail)]

should this go to the offline component of mailnews?

Comment 7

[grylchan]

Sarah, I will defer to you or one of the other developers to
make this call. I don't mind taking it. I think Mitch's
original problem included more than just offline indicator
(security padlock but not sure that is even in the
composition/reply/forw message windows).

Comment 8

[Blake Ross]

--> themes

Comment 9

[Joe Hewitt (gone)]

-> andreww

Comment 10

[andreww]

 windows --> shuehan

Comment 11

[Ari]

This is a far reaching problem that affects many windows:
1. The arrows on the vertical scrollbar in the main browser window is covered by
the grow box when the status bar is turned off and there is no horizontal
scrollbar (This is made worse by the new 'hide toolbar button' on top level windows)
2. The image/cookie manager dialog
3. The form manager and composer 'Advanced Edit' dialogs (bug 100577)
4. The offline indicator in many mail windows including the address book (bug 90489)
5. The 'Customize Sidebar' window (bug 111004)
6. The 'Manage Bookmarks' dialog
7. And probably most other resizable mac windows)

I think that this is a major problem because often important widgets are
covered. UI consistency and correctness is pretty important.

Comment 12

[Lori Kaplan]

nominating. Shuehan will investigate and ue triage will decide whether to approve.

Comment 13

[Lori Kaplan]

reassigning to Andrew. Still not approved. Pending investigation.

Comment 14

[Lori Kaplan]

Too much work to make it in this release. 

Comment 15

[Simon Paquet [:sipaq]]

This bug is targeted at a Mac classic platform/OS, which is no longer supported
by mozilla.org. Please re-target it to another platform/OS if this bug applies
there as well or resolve this bug.

I will resolve this bug as WONTFIX in four weeks if no action has been taken.
To filter this and similar messages out, please filter for "mac_cla_reorg".

Comment 16

[benc]

RESOLVED: WONTFIX.
CFM RIP.
Looks fine in Mac OS X, Mozilla 1.6f.

Comment 17

[Frankie]

OS9 CFM RIP. OSX OK AFAICT.