452824 - URL/status whiteboard fields shorter than before (too short)

Status: RESOLVED FIXED

(bugzilla.mozilla.org :: General, defect)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

The length of the keywords, URL, and status whiteboard fields is now a good 1/4" or so shorter than it was before, and those things were often too short before.

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Not sure why this got filed UNCO; that's not my default setting.

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Note that this is at least the second shrinkage; the December 2006 upgrade shrank these to their previous size (bug 365154) ;)

Comment 3

[Justin Dolske [:Dolske]]

Half-baked idea: Perhaps some of these fields should live in the right-column, and adjust to the window width. [See also: bug 452809, bug 452807].

Comment 4

[Max Kanat-Alexander]

Yes, I think the ideal solution is to make the two top columns flow a bit with the page, along with a min-width (does IE7 support that?). Otherwise, we wouldn't want to expand the left-side text fields, because they'd smash the right column.

Another option is to discard the table-based layout, but I'm not really aware of any good cross-browser solution to make the field labels line up, then.

Comment 5

[Frédéric Buclin]

You don't need larger text fields if their content was initially displayed as plain-text, so that long texts can wrap on two rows. If you want to edit them, just click the (edit) link.

Comment 6

[Samuel Sidler (old account; do not CC)]

I'm not sure that solves the problem. Adding more "edit" links just makes things less usable for people who frequent Bugzilla. It means more clicks to get things done. For example, I don't think the status whiteboard or keyword inputs should be plain text, ever.

I'm definitely in favor of making these fields larger. They keep getting smaller and I don't think that helps anything.

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

For instance, look at bug 452731; the depends block takes up 2/3 of the width of the page (that's probably another bug, actually), while the text fields are still relatively small.

The URL field is not as big of an issue now that it's plain-text and it should be less-edited.  But as Sam notes, the heavily-used keywords and status whiteboard fields should never be plain-text for those with editbugs/etc., and they need to have all the width they reasonably can.  As it is, you can only read about a single whiteboard item, so if for instance you have a "please read" note like bug 452731 and some other status info, you won't be able to read the second item.  I don't have time to run through my buglists for examples, but this is not an uncommon problem.

Comment 8

[Max Kanat-Alexander]

Okay, this is fixed in my repo, I made them grow with the window.

Committing to: /var/www/html/everythingsolved.com/bzr/mozilla/3.2/
modified skins/standard/show_bug.css
modified template/en/default/bug/edit.html.tmpl
Committed revision 6139.

Comment 10

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

This is far, far better than before! Thanks, Max!

One thing I noticed, though, is that what happens on the right side/edge varies when you expand your window width. Compare

https://bugzilla-stage-tip.mozilla.org/show_bug.cgi?id=366269
https://bugzilla-stage-tip.mozilla.org/show_bug.cgi?id=366270
https://bugzilla-stage-tip.mozilla.org/show_bug.cgi?id=351504

In the final bug, you get a much better layout in the right column as you expand the width of your window (mine starts at 867px, for purposes of comparison).  In the first two bugs, people with larger window widths don't get much extra room for status and url and so forth because Boris's "name" unwraps and expands to fill the space (as does the space between the flag name and the flag <select> in the second one).  In both of the first two bugs, the whitespace on the right edge is 50% larger than in the third bug.

As I said before, this is *much* better than before, both in initial size and in "expandability"; I don't know if these other issues can be optimized away, but I did want to mention them (I'm happy to move them to another bug if warranted, too).

Comment 11

[Max Kanat-Alexander]

Yeah, that's a good standard problem with tables. We could set a width on the second column, I don't think that'd hurt anything. You should probably file another bug for it, upstream.

Comment 12

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

> You should probably file another bug for it, upstream.

Bug 465041

Comment 13

[Max Kanat-Alexander]

This has been checked in to bmo.