313816 - Hard to read top 100 bug descriptions in Step 1 of reporting a bug

Status: RESOLVED FIXED

(Bugzilla :: Query/Bug List, defect, P3)

Description

[Richard Karpinski]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

The Top 100 window is very short, vertically, so it is hard to read the content of a truly popular bug. Perhaps when you actually select such a bug to read, you could get a WHOLE PAGE of the content rather than three or four lines at a time. Since it is a Top 100 bug report, you may be suspicious that the contents are looooong and give it some room to stretch out and relax.

Reproducible: Always

Steps to Reproduce:
1.Pick the second bug in Top 100.
2.Read the contents, very slowly and painfully
3.Write that up as a bug. That's what I'm doing.

Actual Results:  
hard to read

Expected Results:  
easy to read

switched to a much larger window so more can be seen before needing to scroll more.

Comment 1

[Frédéric Buclin]

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

Comment 2

[Dave Miller [:justdave]]

Gerv owns this page

Comment 3

[Gervase Markham [:gerv]]

The HTML says that the <iframe> should be 80% of the height of the viewport, but Firefox is ignoring this and using the default height. This behaviour is rendering-mode dependent, and it changed when mkanat added a system identifier to our DOCTYPE in March 2005 in bug 162194. This switched us from Quirks mode to Almost-Standards mode.

We have the following choices:

- Change the page to use a fixed pixel height for the <iframe>
- Find a way to change this template only to have a different doctype, probably by inserting it above [% PROCESS global/header.html.tmpl %]
- Reverse bug 162194

Gerv

Comment 4

[Max Kanat-Alexander]

Wow, the Standards Modes don't allow us to use % heights on an <iframe>?

(I think we already have this bug filed somewhere, by the way.)

I think the best way to go is a fixed-pixel height for the <iframe>.

Comment 5

[Gervase Markham [:gerv]]

Attachment: Patch v.1

Let's go with that, then.

Gerv

Comment 6

[Marc Schumann [:Wurblzap]]

Hmmm... Is this a browser bug? http://www.w3.org/TR/html4/present/frames.html#h-16.5 tells me iframe height values may well be percentages: the height attribute should be a "length" (http://www.w3.org/TR/html4/types.html#type-length).

Comment 7

[Gervase Markham [:gerv]]

I'm not sure; there are a few bugs which discuss the subject, and one makes the point that it's hard to calculate a percentage height if the containing block doesn't have a specific height of its own. When should the percentage refer to the height of the container, and when to the height of the viewport?

CCing roc to see if he can add any clarity.

Gerv

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

#container is height:auto so its %-height children don't work. Try making it height:100%. You might also need height:100% on BODY and HTML. They will overflow vertically anyway so it shouldn't hork the page.

Comment 9

[Gervase Markham [:gerv]]

Attachment: Patch v.2

Ah, nice one. That'll do. This also fixes the problem, but still uses percentages.

Comment 10

[Max Kanat-Alexander]

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

Okay. I trust Roc. :-)

Comment 11

[Max Kanat-Alexander]

I don't see anything wrong with backporting this. It's a template change, but an extremely minor one, on a page that is probably only rarely used in translations.

Comment 12

[Myk Melez [:myk] [@mykmelez]]

I can see 2.22, which is our most recent stable release, but does this really need to go into 2.20?

Comment 13

[Max Kanat-Alexander]

No, I would suppose it doesn't. :-)

I'd imagine justdave might want to apply it to bmo, though.

Comment 14

[Frédéric Buclin]

gerv, too lazy to commit your patch yourself? :-p

Comment 15

[Gervase Markham [:gerv]]

No, just snowed under with stuff. I'll get to it :-)

Gerv

Comment 16

[Gervase Markham [:gerv]]

Checked in on trunk and 2.22 branch. Trunk:

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.34; previous revision: 1.33
done

Branch:

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.26.4.4; previous revision: 1.26.4.3
done

Gerv

Comment 17

[Max Kanat-Alexander]

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

Comment 18

[Frédéric Buclin]

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