372589 - Firefox squishes bugsearch window making it difficult to use

Status: RESOLVED FIXED

(Bugzilla :: User Interface, defect)

Description

[L A Walsh]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2

When I go to bugzilla to report a bug in either Firefox or Mozilla,
search results window (defaulting to top 100 when window initially displayed) is squished under firefox+.  It's only enough to display 1-line summaries of 4 bugs and is about 4cm high.
Under Opera and IE, the window displays 17 and 12 bugs, respectively,  and have vertical heights of about 21 and 22 cm, respectively.  The DPI is set the same (101) in all three browsers.

This makes perusal of the buglist difficult, and, frankly, dissuades me from looking at very many bugs for duplicates (maybe whatever is in the first 2-3 scrolls on each browser, or about 8 bugs on FF.  

Why is this window so darn small on FF?  It's weird that FF can't display full bug-result window on its own bug-manager, but Opera and IE can display full size windows of nearly same height.  Theoretically, I believe, FF's window should be of similar height -- since the screen size is constant on all, and the dpi is constant on all -- so whether or not it computes a window height based on an absolute height (say, 21.5cm high), or a percent of screen height, or percent of window height (windows are all roughly same height -- slightly smaller than screen height), they should be in same ball park, but FF's windows are about 1 fifth the height of the other two browsers. 

I can't imagine this problem is limited to FF, but I don't do side-by-sides on every webpage.  This example is especially "in my face" because it's the main entry for entering FF and TB bugs.

Slightly tangential suggestion -- maybe FF needs to do a bug-fix and code-cleanup, *only*, release -- maybe a redesign of code structure toward more optimality (assuming anyone has thought of more optimal structures, if not, nevermind on that! :-)).  It's just that I notice in many projects, that features keep getting added on, and at some point, due to the way the code has developed, a different structure/organization works "better" (smaller, faster, cleaner, more internal orthogonality/less overlap&duplication...etc). 

Only reason I "side-comment" is that sometimes bugs like this just "fall out/disappear" as a side effect of a code cleanup.  It may be the case that something in the code has "systemically" caused "size" problems due to a some programming "model" that doesn't quite fit the problem space.  The slightly odd fit might not have been a problem before, but as a project expands, a slight-misfit can grow into noticeable problem (a bit like a small pebble in a shoe feeling like a boulder after walking several miles).



Reproducible: Always

Steps to Reproduce:
1. I don't know that any specific steps are required.  I've haven't seen it work correctly since the shift to FF1.5, I /believe/.
2.
3.
Actual Results:  
small window gives portal sized view of ocean's worth of data

Expected Results:  
large window taking up large percentage of screen to allow me to view many bugs at one "glance" without having to scroll (since scrolling uses mouse, and RSI problems make me mouse&typing conservative).

I believe this has been present since shift to 1.5, though for sure since 2.0.
Incorrect sizing of this window is a major problem on this page and, I believe, may be an expression of other size issues in the code, where it doesn't scale output widgets in accordance with text scaling.  Though in this specific case, the problem appears to be exacerbated well beyond, what is commonly the effect of text-widget scaling inconsistencies.

Comment 1

[L A Walsh]

Attachment: image/png

firefox image of page

Comment 2

[L A Walsh]

Attachment: ie6 screen snap showing box size

Comment 3

[L A Walsh]

Attachment: firefox screen snap showing small box size

Comment 4

[L A Walsh]

Attachment: opera screen snap showing best box size

Comment 5

[Phil Ringnalda (:philor)]

The new theme regressed bug 313816 - the iframe used to be a child of the body, so body, html: height: 100% was enough to make a percentage height on the iframe be a percentage of the viewport, but now it's a child of <div id="bugzilla-body">, which is height: auto.

Comment 6

[Max Kanat-Alexander]

Ah, yes. I really don't want to release with a regression we fixed *during* the 3.0 development cycle. Particularly when it's this easy to fix.

Comment 8

[Frédéric Buclin]

gerv, I think we should reverse your change in bug 313816 and use your first patch instead (https://bugzilla.mozilla.org/attachment.cgi?id=229228).

Comment 9

[Gervase Markham [:gerv]]

Putting height:100% on <div id="bugzilla-body"> seems to work as well. Can't we do that?

Gerv

Comment 10

[Frédéric Buclin]

I don't really care, as long as this fixes the problem with major browsers. :)

Comment 11

[Max Kanat-Alexander]

Okay, since this only *strongly* affects bmo, and nobody's taking it to fix it, it's not a blocker. The create-guided that we ship with Bugzilla is only an example, anyway.

Comment 12

[Gervase Markham [:gerv]]

Attachment: Patch v.1

Very simple patch, taking LpSolit's advice.

Gerv

Comment 13

[Max Kanat-Alexander]

Comment on attachment 262493 [details] [diff] [review]
Patch v.1

I'm pretty sure that "px" isn't supposed to be in the HTML.

I'm sad that we're moving away from CSS and into specifying things directly in the HTML, but if that's the only thing that works, then OK.

(If we're going to just specify a px height, why not do it in CSS?)

Comment 14

[Gervase Markham [:gerv]]

The px is definitely supposed to be present - it's what differentiates the number from a percentage, or some other measurement.

I specified it directly in the HTML because that's where it was before, and I wanted a minimally-intrusive patch for 3.0 if possible. If you want me to move it to CSS, I can.

Gerv

Comment 15

[Max Kanat-Alexander]

Yeah, I'd rather move it to the CSS.

And not to belabor the point, but if it does stay in the HTML:

http://www.w3.org/TR/html401/sgml/loosedtd.html#Length

(Linked from http://www.w3.org/TR/html401/present/frames.html#h-16.5 )

Comment 16

[Gervase Markham [:gerv]]

Attachment: Patch v.2

Oops. I just looked at some examples of how "height=" was used :-)

Try this.

Gerv

Comment 17

[Max Kanat-Alexander]

Comment on attachment 262496 [details] [diff] [review]
Patch v.2

Looks correct to me.

Comment 18

[Frédéric Buclin]

tip:

Checking in template/en/default/bug/create/create-guided.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/create/create-guided.html.tmpl,v  <--  create-guided.html.tmpl
new revision: 1.37; previous revision: 1.36
done

3.0 RC1:

Checking in template/en/default/bug/create/create-guided.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/create/create-guided.html.tmpl,v  <--  create-guided.html.tmpl
new revision: 1.36.2.1; previous revision: 1.36
done