228499 - [fix] Aqua form buttons draw incorrectly when the content (text) is to small (and other form widget fixes)

Status: RESOLVED FIXED

(Camino Graveyard :: HTML Form Controls, defect)

Description

[Jasper]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6b) Gecko/20031205 Camino/0.7+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6b) Gecko/20031205 Camino/0.7+

On some occasions the text that is displayed in abutton has only 2 letters (go)
this results in horrible looking icons. For an example go to
http://www.mozilla.org. 

This is also a testcase page:
http://web.mit.edu/bzbarsky/www/testcases/form-baseline/buttonTest-quirk.html?

Reproducible: Always

Steps to Reproduce:
Go to the given url's.
Actual Results:  
The button on mozilla.org is drawn incorrectly.


Fixed issue's:
- introduced a minimum button width to make sure a button <input tupe="reset">
is always drawn correctly.
- adjusted all form widgets margings to make sure that form widgets do not get
painted over or on top each other (spymac forum bug).
- made sure that the <button></button> fom widget has a size that coresponds
with a more general aqua sized button. And is not some kind of odd blob.

Comment 1

[Jasper]

Attachment: modified platform-forms.css file.

This file fixes the issue's mentioned above.

Comment 2

[Jasper]

Some other things we should look at.

- widget focus drawing is no longer present in 10.3 and has always had issues in
Camino, do we still need it?
- shouldn't we introduce a fixed font size and fixed button size to make sure
buttons always look the way they are intended by Apple?
- Is it possible to implement small scroll bars for large text fields and select
fields? Becuase we are now drawing large scrollbars wich cuases some strange
behaviour (scrooll bars that are painted when not necesarry and no sroll bars
when they should be painted?)

Comment 3

[Mike Pinkerton (not reading bugmail)]

bryner thought the min-width should be expressed in the native theme code, not
in css. i'll look at that.

Comment 4

[Mike Pinkerton (not reading bugmail)]

is this a dupe of 221922?

Comment 5

[Ludovic Hirlimann [:Usul]]

find . -name "platform-forms.css"
./camino/build/Camino.app/Contents/MacOS/res/platform-forms.css
./dist/bin/res/platform-forms.css
./dist/Embed/res/platform-forms.css
./dist/MozillaDebug.app/Contents/MacOS/res/platform-forms.css
./layout/html/document/src/mac/platform-forms.css
./layout/html/document/src/os2/platform-forms.css
./layout/html/document/src/win/platform-forms.css

Which one is the one we use ? the one from embed ? or the one from sr/mac ?

Comment 6

[Jasper]

Mike: Well part of Bug 221922 is fixed by this bug (mis shapen buttons, bt not
the margins).

Ludo: ./camino/build/Camino.app/Contents/MacOS/res/platform-forms.css

Comment 7

[Ludovic Hirlimann [:Usul]]

Jasper : nope the file comes from one of the other files Given by the find command.

Comment 8

[Mike Pinkerton (not reading bugmail)]

*** Bug 221922 has been marked as a duplicate of this bug. ***

Comment 9

[Mike Pinkerton (not reading bugmail)]

the one from src/mac gets copied into embed, and that's where we pick it up.

Comment 10

[Mike Pinkerton (not reading bugmail)]

the width however should be in the c++....it's very odd that the css fixes it.

Comment 11

[Jasper]

I agree that there should come a better fix than my current css one. But could
we at least use it untill some one really fixes it. This is one of those bugs
that makes us look like the odd duck. And the temporaray fix I slaped together
is real easy.

Comment 12

[S Woodside]

Jasper do you want a review? Set the review? bit :-)

Comment 13

[Jasper]

Attachment: Pain bank page for buttons. Close you eyes!

I made a html page which contains a collection of all the things going wrong
with buttons in Camino. Conclusion is that we are allowing the use of to much
styles in button resulting in numerous opertunities to break buttons.

- we should not allow any form of styles aprt from font size and weight at max.

- we should give buttons more marging making sure they do not paint over each
other.
- we should introduce minimum button width

That would solve most of our problems. And perhaps it would be even better if
we would just ban all forms of styling, that way our buttons would just look
like any other button on OS X (just like safari). It would rule out any
posibility of  badly drawn widgets.

Comment 14

[Jasper]

I also noticed that buttons that have styled text using pt sizes have different
margins than buttons styled using px sizes?? What's going on there?

Comment 15

[Jasper]

Attachment: Updated the button test page.

Bug 205136 seems to be a duplicate of this bug. It talks about one of the
aspects  mentioned in this bug.

Comment 16

[S Woodside]

I think that we should allow different sizes of text at a minimum. I don't know
if I agree that we should only allow one size of button text. Otherwise I agree
that limiting the styling is OK and assigning a minimum width is good too.

Comment 17

[Mike Pinkerton (not reading bugmail)]

landed jasper's css file. what do we want to do with the other problems? i guess
if we keep this open, we don't need this fixed quite as badly anymore, pushing
out to 1.0

Comment 18

[Jasper]

some hints to really fix this should be found here:
http://www.mozilla.org/projects/xul/theme.html

Comment 19

[Jasper]

Ok I tracked down the border issue more.

In platform-forms.css we define the button border for aqua buttons as follows:
border-width: 2px 8px 2px 8px;

Comment 20

[Jasper]

Ok I tracked down the border issue more.

In platform-forms.css we define the button border for aqua buttons as follows:
(border-width: 2px 8px 2px 8px;

Comment 21

[Mike Pinkerton (not reading bugmail)]

jasper, I'm not sure what that nsITheme page points out...that's already how
we're implementing this.

Comment 22

[Jasper]

Attachment: Added some radio, check boxes, input fields (disabled).

I will add a new .css that will fix othyer things.

Comment 23

[Jasper]

Attachment: Fixes some other visual form bugs.

Ok this css file fixes the following bugs:
- check boxes are not correctly vertically alligned with text baseline
- radio buttons are not correctly vertically alligned with text baseline
- text in input doesn't align with the base line of text outside of it
- disabled text fields have mozilla style instead of our style

Result:
We look yet again better than before, we are looking very much like native
widgets. We even look better than Safari on some points :)

Comment 24

[Jasper]

Mike,

The problem as I tracked it down for the border style issue is as folows.

1) We have nsITheme that lays out the basic buton styles by using the aqua
resources and XUL?
2) we have a platform-forms.css document that fine tunes the results comming
from nsITheme.
3) but when ever a webpage has certain custom styles for form elements nsITheme
overrides the platform-forms.css settings.

The border issue is a result of this. Platform-forms.css gives detailed
information on how to paint a button by using a border-width style method to
make sur the text is nicely aligned within the button. But when a page has
custom border style in it's button it overrides the detailed border in
platform-forms.css resulting in a malformed button.

Unless ofcorse if the border style in the button is axactly the same as in
platfor-forms.ccss, which is a small chance.

Comment 25

[Jasper]

Attachment: Added some more fixes and new methods

In this version I tried a new approach to dawing the buttons to make sure the
border issue get fixed. And it works :), except if we have a button size and
spacing style in one button. But still is 10x better than what we had.

New fixes:
- fixed diabled buttons
- tweeked alignment of radio and check boxes
- also tweeked all the widgets to make sure that the button text baselines now
are on the same hight as the page text basline.

Please test and look closely to all the different pages that use forms to see
if there is anything else we could fix.

Comment 26

[Jasper]

Attachment: Took out the other border method.

Same fixes but slightly tweeked to work on morepages correctly.
Took out the new border drawing method, still not good enough.

Comment 27

[Jasper]

Attachment: v6 Taken out the text alignment that cause probs on a site from Mike

I took out parts of the css that aligned most form widgets. since it caused
some trouble on several webpages :)

I also simplified some of the css by combining styles which results in more
compact css and has the same functionality.

Comment 28

[Mike Pinkerton (not reading bugmail)]

landed last patch, closing out bug.