User Agent string in the About Firefox dialog is cut off at the bottom

VERIFIED FIXED

Status

()

Firefox
General
P5
trivial
VERIFIED FIXED
15 years ago
5 years ago

People

(Reporter: Greg Campbell, Assigned: Aaron Slunt)

Tracking

({polish, verified1.8})

Trunk
polish, verified1.8
Points:
---
Bug Flags:
blocking-aviary1.0 -
blocking1.8rc1 -
blocking-aviary1.5 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: testrunner, URL)

Attachments

(17 attachments, 15 obsolete attachments)

79.26 KB, image/png
Details
43.23 KB, image/png
Details
905 bytes, patch
Details | Diff | Splinter Review
93.71 KB, image/png
Details
4.79 KB, patch
Details | Diff | Splinter Review
112.34 KB, image/png
Details
3.00 KB, patch
mconnor
: review+
dveditz
: superreview+
Details | Diff | Splinter Review
43.50 KB, image/png
Details
371 bytes, patch
Details | Diff | Splinter Review
980 bytes, patch
mconnor
: review-
Details | Diff | Splinter Review
73.18 KB, image/png
Details
74.08 KB, image/png
Details
28.61 KB, image/gif
Details
34.55 KB, image/gif
Details
34.56 KB, image/gif
Details
28.56 KB, image/gif
Details
88.52 KB, image/png
Details
(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040319 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040319 Firefox/0.8.0+

The second line of text of the user agent string is cut off by about 1 or 2 px
at the bottom. If you select both lines of text a continue moving the mouse
downward, the text scrolls up slightly and you can see the bottom of the cut-off
parentheses.

Just a few builds ago, the user agent was in a scroll box. Now that box is gone
(and it looks better because of it).

Reproducible: Always
Steps to Reproduce:

Comment 1

15 years ago
WFM 20040320 PC/WinXP

Comment 2

15 years ago
I see what you are talking about the ) and / in the bottom line are slightly
trimed compared to the ( and / in the top line.
(Reporter)

Comment 3

15 years ago
Created attachment 144455 [details]
Screenshot illustrating bug

Comment 4

14 years ago
*** Bug 240349 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 5

14 years ago
Bug 240349 has a screenshot from linux with the text cut off significantly more
than my screenshot from WinXP. OS->All.
OS: Windows XP → All
(Reporter)

Updated

14 years ago
Keywords: polish
(Reporter)

Comment 6

14 years ago
This bug is in the branch: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7) Gecko/20040521 Firefox/0.8.0+

blocking1.0?

Flags: blocking1.0?

Comment 7

14 years ago
See bug 237804 and bug 234920.
The user agent string is actually in a scrolling area...
Confirming.

I am seeeing this on firefox 20040521 on debian sid.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 9

14 years ago
*** Bug 244739 has been marked as a duplicate of this bug. ***

Comment 10

14 years ago
this should be really simple to fix... 
 
The only problem is, that I have no idea what file contains that page! 
 

Comment 11

14 years ago
(In reply to comment #10)
> this should be really simple to fix... 
>  
> The only problem is, that I have no idea what file contains that page! 
>  

http://lxr.mozilla.org/seamonkey/source/browser/base/content/aboutDialog.css#32

Comment 12

14 years ago
I found it... but repacking my changes into the  
chrome/browser.jar/aboutDialog.XUL didn't help.. I suppose I should try  
the .css  ... or maybe the en_US local.. sigh..  
-ing will take patch
Flags: blocking1.0? → blocking1.0-

Comment 14

14 years ago
Created attachment 149609 [details] [diff] [review]
Increase height of UA string textbox to avoid scrolling

The problem is that the XUL element gets a bunch of internal padding.  It gets
2px from the @id-specific rule in browser/base/content/aboutDialog.css and 2px
from the <input> generated inside the textbox by XBL (via
layout/html/document/src/forms.css).  That totals 4px of internal padding, and
the textbox's height is set to 2.4em.  If 0.4em < 4px, scrolling will happen. 
I tried counting pixels on my computer and got 9px per line.  Therefore 0.4em
is ~ 3.6px, which is less than 4px and thus generates scrolling.

The fix is just expanding the height of the textbox from 2.4em to 2.6em.  I
tried 2.5em as well, but that generated scrolling (probably something I missed
somewhere - my guess is some effect of <input> border), so I upped it to 2.6em,
which is what this patch implements.  It's WFM by editing-browser.jar-in-place
to test.
Assignee: firefox → jwalden+bmo
Status: NEW → ASSIGNED

Comment 15

14 years ago
Comment on attachment 149609 [details] [diff] [review]
Increase height of UA string textbox to avoid scrolling

Requesting review from mconnor...
Attachment #149609 - Flags: review?(mconnor)
*** Bug 251734 has been marked as a duplicate of this bug. ***

Updated

14 years ago
Whiteboard: testrunner http://testrunner.mozilla.org/test.cgi?run_id=242#795

Comment 17

14 years ago
Heh...this bug seems to have fallen by the wayside.  It's a trivial fix for a
trivial bug, so by my thinking it's a 1.0 bug.

Rerequesting blocking-aviary1.0? per comment 13 (I think it's the correct action
here, sorry if it's not) to get this on the radar...
Flags: blocking-aviary1.0- → blocking-aviary1.0?
Whiteboard: testrunner http://testrunner.mozilla.org/test.cgi?run_id=242#795 → testrunner [have patch]
(Reporter)

Comment 18

14 years ago
While the current patch seems to fix the problem in the short term, I think a
better long term solution would be to auto-size the height of the about box to
accomodate the whole UA string.

The current UA string (which is a little weird) is: Mozilla/5.0 (Windows; U;
Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040902 Firefox/1.0 PR (NOT FINAL)

This string actually wraps to a third line, and must be scrolled even though
there is no scrolling mechanism. Even though this string won't last long, UA
strings with a builder or vendor comment added in would probably have the same
problem.

Comment 19

14 years ago
It seems to be theme-dependent, I see this when using the default winstripe
theme, but not with the theme I am currently using (Noia:
http://www.deviantart.com/view/4266778/). I did not try to see what the author
did to correct this.

Comment 20

14 years ago
mconnor, can you review.  lets get this in quick and out of the way if we are
going to take it.

Comment 21

14 years ago
think that we are going to be too overloaded to get to this for 1.0...  -minus
blocker nomination
Flags: blocking-aviary1.0? → blocking-aviary1.0-

Comment 22

14 years ago
Created attachment 165372 [details]
screenshot

Truly pitiful that this wasn't fixed before 1.0.

Comment 23

14 years ago
*** Bug 269314 has been marked as a duplicate of this bug. ***

Comment 24

14 years ago
This seems to have worsened on the trunk since the merging with the branch! Can
anyone confirm?

I am using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6)
Gecko/20041204 Firefox/1.0+ and there seem to be more lines missing than before.

Comment 25

14 years ago
*** Bug 254168 has been marked as a duplicate of this bug. ***

Comment 26

14 years ago
*** Bug 274262 has been marked as a duplicate of this bug. ***

Comment 27

14 years ago
Setting the nomination flag to block to bring this bug onto the radar.

I know that this is a "cosmetic" problem only but...

+ the fix is a one liner only!
+ the glitch is pretty obvious (exspecially on Linux, but on Windows, too)
+ it fell off the radar already one time
Flags: blocking-aviary1.1?
blocking is "we won't ship with this" not an attention flag.
Flags: blocking-aviary1.1? → blocking-aviary1.1-

Comment 29

14 years ago
*** Bug 255438 has been marked as a duplicate of this bug. ***

Comment 30

14 years ago
*** Bug 283819 has been marked as a duplicate of this bug. ***

Comment 31

14 years ago
Created attachment 175958 [details]
screenshot of 1.0.1 @ 120 DPI

shame, shame

Comment 32

14 years ago
(In reply to comment #31)
> shame, shame

3 screenshots have already been attached to this bug showing what the problem
is. No need for more.

Comment 33

14 years ago
*** Bug 234920 has been marked as a duplicate of this bug. ***
theres already a patch for this. can someone review it and check it in?
If someone is looking for an artistic way of fixing this bug -- looking for
something that is much more than just a plain fix ;-) -- then you may try my
Firefox extension at http://Mithgol.Ru/Mozilla/Firefox/
i think it would just be better to check in the patch. i dont think i could
stand a communist about box.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050322
Firefox/1.0+
The patch in comment 14 fixes this problem for me.
it fixes it for everybody. its just that _nobody_ wants to check it in.
(Reporter)

Comment 39

13 years ago
I think the comment that this "fixes it for everybody" is a baseless claim. So
far as I can tell, everyone who has chimed in that the patch fixes the problem
has been a Windows user. The last two posted screenshots are from a Linux and
OS/2 user whose useragent string takes more than 2 lines, cutting off a
significant portion of the string. A >2-line useragent string isn't going to fit
in a box with 2.6em height (as the patch implements).

Notice the ifdef for Mac, allowing 3 lines for the Mac string. Using an ifdef
for each platform seems like a messy solution.

As I mentioned in comment 18, a better solution probably needs to be devised to
accomodate users using a variety of text sizes.

That said, the current patch would be a reasonable band-aid for Windows users,
fixing the trivial problem for scores of users without making it worse for anyone.

Please don't use bugzilla as your personal whining forum. If you don't have any
useful additional information to add--such as a better patch, or insight into
how this affects various platforms--don't say anything at all.
(In reply to comment #39)

> The last two posted screenshots are from a Linux and
> OS/2 user whose useragent string takes more than 2 lines, cutting off a
> significant portion of the string. A >2-line useragent string isn't going to fit

> That said, the current patch would be a reasonable band-aid for Windows users,
> fixing the trivial problem for scores of users without making it worse for anyone.

I think a better interim patch would be to just remove the ifdef logic and make
it 3.8em for all platforms until a real fix is devised.  If we are going to do a
temporary band-aid, it should not be a windows only band-aid.  Making it 3.8em
for all platforms would fix this for Linux and non-official builders of Windows
who add there own buildinfo to the string.

Comment 41

13 years ago
William, could you provide a patch? I agree that this would be the best interim
solution. Linux should be fixed as well.

Comment 42

13 years ago
Created attachment 179047 [details] [diff] [review]
Patch based on proposed solution.

Giving review a shot. Sorry if I'm stepping on any toes, just would like to see
a fix checked in soon.
Attachment #179047 - Flags: review?(mconnor)
*** Bug 287881 has been marked as a duplicate of this bug. ***

Comment 44

13 years ago
*** Bug 289239 has been marked as a duplicate of this bug. ***

Comment 45

13 years ago
height: 2.4em; is too small for XP it needs to be at least 2.6em.

Comment 46

13 years ago
(In reply to comment #45)
> height: 2.4em; is too small for XP it needs to be at least 2.6em.

The proposed patch sets it to 3.8em on all platforms.

Comment 47

13 years ago
(In reply to comment #17)
> Heh...this bug seems to have fallen by the wayside.  It's a trivial fix for a
> trivial bug, so by my thinking it's a 1.0 bug.

I don't think this is a trivial bug. users are asked many times to tell or copy
there useragent for troubleshooting purposes, and putting it inside a box that
has no scrolling can make it complicated for novice users to figure (the ones
that usually need the troubleshooting). not everyone knows the trick of "put
your'e mouse at the begining of sentence, click the mouse and drag down until
you see the end" ;) i think the severity of this bug should really be normal.
The fix to make it just always have room for 3 lines may be trivial, but now
that the fix for bug 238137 has landed, which generalizes the method for adding
application defined fields to the user-agent string, the code really needs to be
fixed to adjust the size to account for an arbitrary length user agent string.
(In reply to comment #48)
> The fix to make it just always have room for 3 lines may be trivial, but now
> that the fix for bug 238137 has landed, which generalizes the method for adding

Sorry for bugspam.  I mant to say the fix for bug 274928.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050417
Firefox/1.0+

->WFM

This was resolved by Bug 289217

Comment 51

13 years ago
Not to be a stickler, but it is still cut off, just now only the bottom tips of
the foward slashes.

Comment 52

13 years ago
(In reply to comment #51)
> Not to be a stickler, but it is still cut off, just now only the bottom tips of
> the foward slashes.

I agree, it's still a bit cut off.. but I think it still depends on the fix
given by bug 289217.. so it was probably supposed to be fixed there again.
(Reporter)

Comment 53

13 years ago
Still not fixed on WinXP 96dpi. Mine now looks exactly the same as attachment
144455 [details] (it had gotten worse, this is back to how it was when I reported the
bug). Descenders below the baseline are still cut off. Select the UA string and
drag down; the text scrolls about 2 pixels. That behavior means the area alotted
for this text is not tall enough. It's close, but not quite.

Did the checkin from bug 289217 improve this bug on any other platforms or
logical resolutions?
(In reply to comment #18)
> While the current patch seems to fix the problem in the short term, I think a
> better long term solution would be to auto-size the height of the about box to
> accomodate the whole UA string.

Is it possible to do this, rather than just picking an arbitrary height?
(Assignee)

Comment 55

13 years ago
Created attachment 181270 [details] [diff] [review]
Let firefox automatically calculate the appropriate box size

This replaces the set em amount with auto instead, so it turns out as
height:auto;. I have tested and ran it on this current build (Mozilla/5.0
(Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050419 Firefox/1.0+), and
I no longer have any kind of scrolling or chopped off parts of the user agent
string.
(Assignee)

Updated

13 years ago
Attachment #181270 - Flags: review?(slunta)
(Assignee)

Updated

13 years ago
Attachment #181270 - Flags: review?(slunta)
(Assignee)

Updated

13 years ago
Attachment #181270 - Flags: review?(slunta)
Attachment #181270 - Flags: review?(mconnor)
Comment on attachment 181270 [details] [diff] [review]
Let firefox automatically calculate the appropriate box size

this is probably better, but someone needs to submit this as a diff, not a
whole source file
Attachment #179047 - Attachment is obsolete: true
Attachment #179047 - Flags: review?(mconnor)

Comment 57

13 years ago
Created attachment 181292 [details] [diff] [review]
Diff based on new submitted patch.

Here is a diff based on the new patch submitted earlier. Hope this is fine.
Attachment #181292 - Flags: review?(mconnor)
(In reply to comment #57)
> Created an attachment (id=181292) [edit]
> Diff based on new submitted patch.
> 
> Here is a diff based on the new patch submitted earlier. Hope this is fine.

This patch seems to do the trick.
Attachment #181270 - Attachment is obsolete: true
Attachment #181270 - Flags: review?(mconnor)

Comment 59

13 years ago
Comment on attachment 181292 [details] [diff] [review]
Diff based on new submitted patch.

Since height: auto is the default isn't specifying it redundant? Also isn't
overflow: hidden unnecessary without an explicit height?

On this Win98 Trunk build the patch leaves a 1cm white gap below the UA box, it
looks like the textbox is taking up 3 rows of room even though it only appears
to be using 2 rows.
Flags: blocking-aviary1.1- → blocking-aviary1.1?
mozillafirebird@gmail.com: Please read comment 28.
Flags: blocking-aviary1.1? → blocking-aviary1.1-
theres already a patch waiting to be review. no release should be shipped with
patches waiting to be reviewed. that was my rationale for renominating it.
Created attachment 181630 [details] [diff] [review]
Remove hardcoded height, adjust margin
Assignee: jwalden+bmo → gavin.sharp
Attachment #149609 - Attachment is obsolete: true
Attachment #181292 - Attachment is obsolete: true
Attachment #181630 - Flags: review?(mconnor)
Attachment #181292 - Attachment is obsolete: false
Attachment #181292 - Flags: review?(mconnor)
Attachment #149609 - Attachment is obsolete: false
Attachment #149609 - Flags: review?(mconnor)
Attachment #149609 - Attachment is obsolete: true
Attachment #181292 - Attachment is obsolete: true
Hardware: PC → All
Target Milestone: --- → Firefox1.1
Version: unspecified → Trunk
what does adjusting the margin do? the extra line done at the bottom is still
there for me.
I have done some playing around with this by just overriding these values in my
userChrome.css file.  The conlusion I have reached is that (at least in windows)
the userAgent textbox always ends up being exactly 3 text lines high if you do
not specify a height.  The best I have been able to do is to make it look better
by changing the padding on the detailsBox to 1px.

I think the problem here is that the problem is in the XUL for the aboutDialog
and we are trying to compensate in the css file.

I currently have this in aboutDialog.css in by profile chrome folder.

#detailsBox {
  padding: 8px 10px 1px 8px !important;
}

#userAgent {
  margin: 3px 10px 3px 5px !important;
  background-color: #FFFFFF !important;
  color: #000000 !important;
  padding: 1px 0px 1px 3px !important;
  heigth: auto !important;
  width: auto !important;
  border: none !important;
  -moz-appearance: none !important;
}
(In reply to comment #64)
>   heigth: auto !important;

Hmm. think I need a spellchecker.

Obviously,height would work better here. :-)

Comment 66

13 years ago
William A. Gianopoulos, your solution in comment #64 is perfect!

It's better than the the currently proposed patch (attachment 181630 [details] [diff] [review]).

If you can, make a new patch please do.
Created attachment 181682 [details] [diff] [review]
William's approach
Attachment #181630 - Attachment is obsolete: true
Attachment #181630 - Flags: review?(mconnor)

Comment 68

13 years ago
(In reply to comment #67)
> Created an attachment (id=181682) [edit]
> William's approach
> 

Gavin, can you set some review flags on it? This patch is so simple and safe
(all it does is change some CSS for the about box) that I hope that it gets
reviewed, checked in 1.8b2 and forgotten :)
Attachment #181682 - Flags: review?(mconnor)
Priority: -- → P5
Whiteboard: testrunner [have patch] → [patch-r?] testrunner

Updated

13 years ago
Flags: blocking-aviary1.1- → blocking-aviary1.1+

Updated

13 years ago
Flags: blocking-aviary1.1+ → blocking-aviary1.1-
Flags: blocking1.8b2?
Flags: blocking1.8b2?
Flags: blocking1.8b2?
Please, stop requesting blocking status for such a minor detail. This is not
going to block any releases.
Flags: blocking1.8b2?
(Assignee)

Comment 70

13 years ago
Here's a method which I think is better (as it'd support any user agent)

Edit the aboutDialog.js file to include this function

function measure()
{
	var container = document.getElementById("userAgent");
        //Math.ceil(container.offsetWidth/aboutDialog.style.offsetWidth);
}

Doing that, we can get the width of the useragent text if we let firefox
automatically calculate the width of the useragent label. Then, we can divide
the length by how many pixels wide the textbox is for the useragent, and round
that up to determine how many lines it should be. Set the height using
javascript based on how many lines the useragent will be. If anyone's following
me and thinks this should be how it is, please let me know and I'll create it,
as this will support any useragent set there.
setting the height to auto, which is the current solution, would do the exact
same thing, just more simply.
(Reporter)

Comment 72

13 years ago
Created attachment 182891 [details]
Screenshots with "William's apprach"

This is two screenshots applying the changes from attachment 181682 [details] [diff] [review]. One is
Windows XP set to extra large fonts; the default useragent string takes 4 lines
at this size, forcing vertical scrolling.

The other is Windows XP with normal sized fonts, but with a very long custom
user agent string. It also takes 4 lines, and again forces vertical scrolling.

Any time the useragent is longer than 3 lines, this patch creates scrollbars
since it removes overflow:hidden. It's also possible to get horizonal
scrollbars if you include a very long word in a custom user agent string.

I personally don't think scrollbars are so bad to accomodate strings longer
than the default, but should never occur using the default string.

Since this doesn't fix the default situation for Windows users with extra-large
fonts (or probably any other system at a large font size like 120dpi), I don't
think the current patch is really a "fix."
ok, ur right. go ahead and develope the patch and ill try it out.
Assignee: gavin.sharp → nobody
Status: ASSIGNED → NEW
Whiteboard: [patch-r?] testrunner → testrunner
Target Milestone: Firefox1.1 → ---
(Reporter)

Comment 74

13 years ago
(In reply to comment #70)

Set a reasonable maximum height in the calculation, so the About box can't be
resized to be larger than the screen height.
(Assignee)

Comment 75

13 years ago
The only problem I'm encountering, and is a big one, is that the js doesn't seem
to want to calculate the offsetWidth. I have tried getting the offsetWidth from
other elements, such as the client box, but it returns as undefined (and yes, I
do have experience with using offsetWidth and offsetHeight attributes). If
anyone knows why, please tell me.
(Assignee)

Comment 76

13 years ago
Alright, I seem to have gotten it for normal UA strings.

Am I to compensate also for obnoxiously long strings, including those that force
the useragent box to scroll horizontally? If so, I'll need to make some
adjustments: if not, it should be fine the way it is.
(Assignee)

Comment 77

13 years ago
(In reply to comment #76)
> Alright, I seem to have gotten it for normal UA strings.
> 
> Am I to compensate also for obnoxiously long strings, including those that force
> the useragent box to scroll horizontally? If so, I'll need to make some
> adjustments: if not, it should be fine the way it is.

Example

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050508
Firefox/1.0+ the brown fox jumps over the moon the brown fox jumps over the moon

That useragent works fine.

Here's one that's currently throwing it off

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050508
Firefox/1.0+omgomogmog omgomogmomgomgomogmogmoogmogogmogmgomgogmomgogmogmogomgoog

What happens is that it forces the textbox to scroll and such, and also can
throw off calculations by having one word take up 20 cols, and the next taking
up 45, which causes the next word to be printed on the next line, skipping 40
cols, 2/3 of pixel space, which throws off calculations. If I really need to
make something to support retarded UAs, I can make up a separate algorithm for
them if a very long words are present.

Comment 78

13 years ago
I have this problem with a default install of windows, no font changes. As
illustrated in the first screenshot. Really makes firefox look tacky.
i dont think u need to compensate for horizontal scrolling. what u have works
fine. now u can just post the patch so we can all try it out and it can be
checked in.
(Assignee)

Comment 80

13 years ago
Allow me time after school today to get CVS, and I'll submit the patch. I tested
it in different screen resolutions, and it works. Just hang tight.
(Assignee)

Comment 81

13 years ago
Created attachment 183445 [details] [diff] [review]
patch to support any legit useragent

This calculates how many lines the box will be: makes a hidden box, calculates
the width of that, and divides it by the useragent's box. That number is
rounded up, and then divided by 1.2. That number is then set as the height of
the useragent box, preventing overflow. Note that I have not tested this on
screen resolutions other than 800x600 and 1024x768, but by the logic, there
should be no problem with any others. Sorry if this patch wasn't put together
correctly, but it's my first one.
the patch shows up as jibberish.
(Assignee)

Comment 83

13 years ago
(In reply to comment #82)
> the patch shows up as jibberish.

It's a .tar.gz file, since it required multiple files being editted.

(Assignee)

Comment 84

13 years ago
Comment on attachment 183445 [details] [diff] [review]
patch to support any legit useragent

changing mime-type
(Assignee)

Comment 85

13 years ago
Dammit, the mime-type won't change...

Would it be acceptable to submit the patch as one file, separated in three
sections, a section for each of the editted files?
(In reply to comment #85)
> Dammit, the mime-type won't change...
> 
> Would it be acceptable to submit the patch as one file, separated in three
> sections, a section for each of the editted files?

How about just creating a diff of the three changed files like you're supposed to?
http://www.mozilla.org/hacking/life-cycle.html
(Assignee)

Comment 87

13 years ago
I did create diffs, I just thought I had to pack them all into one file. Are you
saying to submit all three separately?
(In reply to comment #87)
> I did create diffs, I just thought I had to pack them all into one file. Are you
> saying to submit all three separately?

No, you need to provide a single patch that includes all three files, created
using cvs diff, preferably with the -up8 parameters.
No, I'm saying to combine them into one diff for all three files (though you can
also just submit all three individually - it's not as elegant, but it would
work). When you do the diff command, you can list multiple files to be diffed.
(Assignee)

Updated

13 years ago
Attachment #183445 - Attachment is obsolete: true
(Assignee)

Comment 90

13 years ago
Created attachment 183455 [details] [diff] [review]
patch to support legit useragents

Sorry about the mess guys.
Created attachment 183460 [details] [diff] [review]
Fixed version of previous patch

This fixes the issues with applying the patch to the source tree.
Attachment #183455 - Attachment is obsolete: true
Attachment #183460 - Flags: review?(mconnor)
I should also note that I cleaned up some whitespace issues with the previous
patch. Other than that, it's still the same patch as was previously submitted.
Good news is that the patch appears to work.
(In reply to comment #93)
> Good news is that the patch appears to work.

I take that back. I set font sizes to Extra Large in the Display control panel
and I still get vertical scrollbars on the about dialog useragent string
(Assignee)

Comment 95

13 years ago
Here's the problem that I can see out of it:

Whenever you set to extra large fonts, the big fonts end up creating large
spaces that won't show in the hidden box, but shows up on the useragent box (if
any gets what I'm saying).

The only other solution I can think of, and probably might be the best, is to
iterate through each token in the useragent, and add up the lengths of the
tokens until the next token will be greater than the useragent box width. This
shouldn't have any performance issues, so if that's alright, I can get to work
on that.
(Assignee)

Comment 96

13 years ago
One more question: does anyone know if the text wraps because of the number of
columns in the textbox, the width of it, or any of the two?
(Assignee)

Comment 98

13 years ago
Created attachment 183661 [details] [diff] [review]
another version

This version iterates through the string to get the length of each piece of the
useragent, and in turn calculates the height from it. The problem is that is it
not precise (I can't help it, I've tried everything to make it so), so anything
past 4 lines will result in an expanding blank section under the useragent
string (but the useragent shouldn't be that fricking long anyways). Unless I
missed something, the DPI still affects it: I dont' know what to do about this!
I'm getting pixel calculations for each token of the useragent, and still am
not getting the correct height in the end (unless it's my computer). If someone
else can test it with a 120 DPI, please let me know if it works for you or not.
If this doesn't work, I don't know what else to tell you guys or to do: just
living with the overflow for high DPI is the only solution I can think of if
this really does fail.
(Assignee)

Comment 99

13 years ago
Created attachment 183725 [details] [diff] [review]
compensates for 120 DPI

I think this is the one...after reading comment 14, I put the padding into the
calculations as Jeff describes. Also, I adjusted the height to be a bit more to
help compensate for 120 dpi, but I think this is the one.
Attachment #183661 - Attachment is obsolete: true
(Assignee)

Comment 100

13 years ago
Comment on attachment 183725 [details] [diff] [review]
compensates for 120 DPI

Mr. Connor, your take on this?
Attachment #183725 - Flags: review?(mconnor)
QA Contact: bugs.mano → general

Comment 101

13 years ago
Thats a lot of code for a user agent string... man, who would have thought how
fustrating this could be.

Updated

13 years ago
Blocks: 163993

Updated

13 years ago
No longer blocks: 163993

Comment 102

13 years ago
Why does the window need to be so small as to cause this ugliness to persist so
long and be so difficult to fix? Just make it bigger! It's not like this window
is going to get left up in anyone's way any length of time.
(Assignee)

Comment 103

13 years ago
Calm down, the patch is pending review.
Flags: blocking1.8b3?
Please stop asking for blocking status, this bug won't block any release.
Flags: blocking1.8b3?
why wont anyone review the patch?

Comment 106

13 years ago
Someone almost certainly will review the patch. The question is when - people
are busy and this is hardly an issue which needs to be fixed for alpha releases.
Adding more comments is not going to speed things up.
(Assignee)

Comment 107

13 years ago
Has anyone else tested it, so I know if it's alright or if it needs work?
ive tested it and it needs work.
sorry, i meant to say that it wfm. disregard my previous comment.

Comment 110

13 years ago
Here's an interesting thing I found: this bug still exists no matter how large
the window is.  Example:
chrome://browser/content/aboutDialog.xul
Go to that.  The ua string is _still_ cut off, even though it has _far_ more
space than it would ever need...
And we have a patch, let's get it friggin' checked in already; I can assure you
that it won't break anything...
(Assignee)

Comment 111

13 years ago
Created attachment 187035 [details] [diff] [review]
Fixed a whitespace problem, changed measuring function name

Just fixed some whitespace problems, and changed the function name from
"measure" to "measureUADimensions" for easier understanding.
Attachment #183725 - Attachment is obsolete: true
Attachment #187035 - Flags: review?(mconnor)
(Assignee)

Updated

13 years ago
Attachment #183725 - Flags: review?(mconnor)
(Assignee)

Comment 112

13 years ago
Created attachment 188060 [details] [diff] [review]
css fix

Yeah, I'd like to kinda shoot myself over making that hack that does about as
much as this <_<

The problem with william's approach was the extra padding still left in
it...this patch will work with 120 dpi. The default string will NOT scroll;
more than likely longer custom strings will, but for now, the default does not
scroll.
Attachment #187035 - Attachment is obsolete: true
Attachment #188060 - Flags: review?(mconnor)
(Assignee)

Updated

13 years ago
Attachment #187035 - Flags: review?(mconnor)
isnt this patch a step backward? a previous patch calculated how big the box
should be. this is back to the beginning where it only works with the default. i
think the best patch so far would be the 2005-06-22 patch.
(Assignee)

Comment 114

13 years ago
Many have said it was overkill. I kinda have to agree somewhat: i understand why
you want most strings to be accomodated to this, but when it comes down to it,
this is a very simple fix, and if someone knows enough to change their
useragent, then they should know enough about the risks of breaking features.
true. ok, this patch has my blessing. hopefully, this will get checked in in
time for 1.1a2.

Comment 116

13 years ago
None of the other patches in this bug have gotten a review, so why is there any
reason to believe that this one will. Common mconner or anyone else who is
qualified to review this simple patch to fix a long-standing bug with 62 votes!!
Yeesh, let's get some perspective here.  This is not a major bug.  Its a very
trivial UI bit in a little-used dialog.  It'll get done, but its not like its
critical to an alpha to make sure the bottom couple of pixels aren't cut off. 
The last fix is probably right, but it'll come in time.

I think a lot of people who have commented in this bug should read
http://www.bikeshed.com/
if its so trivial why dont u just check it in? the possibility of fallout is
near zero. actually, it is zero. a checkin would be short and sweet. and then
the 62 of us would all go away.
(Reporter)

Comment 119

13 years ago
Created attachment 188735 [details]
Screenshots with "css fix"

Screenshot of Attachment 188060 [details] [diff].

Looks perfect using normal fonts on WinXP (luna). Large fonts doesn't scroll,
but leaves little space between the UA string at the gray space at the bottom
of the dialog. Extra large fonts causes scrolling with a scrollbar with the
default string; the scrollbar extends all the way down to the top of the gray
space.

It's not bad, but could be better. How cosmetically perfect do we want this for
users using larger-than-normal fonts?

Coldfusion: don't get your panties in a wad. I filed this bug and I would
prefer that it be fixed right; time isn't critical here. This is trivial and
cosmetic. Did you even *try* the patch in any configurations other than your
normal browsing configuration before giving the patch your "blessing"? Did you
try it at all?

I'm not a good enough coder to help out here, so I'm grateful that others are
willing to take the time to submit patches for such a barely-noticeable
cosmetic bug that I happened to notice and file. You don't fix a hole in the
wall by hanging a picture over it. Pipe down until you're ready to do real
testing, or ready to submit a better patch yourself.
ive tested this patch. ive tested every patch since the first one. it definitely
works. and i would rather it be reviewed and turned down than not reviewed at
all. just like judicial nominees, every patch should have an up or down vote.
(Assignee)

Comment 121

13 years ago
(In reply to comment #119)
> Created an attachment (id=188735) [edit]
> Screenshots with "css fix"
> 
> Screenshot of Attachment 188060 [details] [diff] [edit].
> 
> Looks perfect using normal fonts on WinXP (luna). Large fonts doesn't scroll,
> but leaves little space between the UA string at the gray space at the bottom
> of the dialog. Extra large fonts causes scrolling with a scrollbar with the
> default string; the scrollbar extends all the way down to the top of the gray
> space.
> 
> It's not bad, but could be better. How cosmetically perfect do we want this for
> users using larger-than-normal fonts?
> 
> Coldfusion: don't get your panties in a wad. I filed this bug and I would
> prefer that it be fixed right; time isn't critical here. This is trivial and
> cosmetic. Did you even *try* the patch in any configurations other than your
> normal browsing configuration before giving the patch your "blessing"? Did you
> try it at all?
> 
> I'm not a good enough coder to help out here, so I'm grateful that others are
> willing to take the time to submit patches for such a barely-noticeable
> cosmetic bug that I happened to notice and file. You don't fix a hole in the
> wall by hanging a picture over it. Pipe down until you're ready to do real
> testing, or ready to submit a better patch yourself.
> 

Look, we can't satisfy everyone here.

The js hack I had earlier submitted might work, but this could cause a
performance hit to other UI threads that could very well be present, so it's
best IMO not to use the hack.

How many people do you know use extra large fonts? Better yet, what's the global
percentage of people who do use extra large fonts, to large fonts? I'd say that
if someone can't see their screen well, they probably would change their screen
resolution as they most likely would also have trouble seeing images and such.

While I believe something should be checked in before 1.1, it's not that much of
a big deal, and hell, there might be a perfect way to fixing this without making
bloated hacks, that could be found between now and then, so please let's all
ease up a bit on this. If a perfect way is found, then it will be submitted, and
it will please even more. I'll possibly spend a bit more time on this in hopes
of trying to get it to work for all cases, but no one feature can satisfy all.

Please understand this.
my point is just that a temporary solution is still a solution. we can use
either the css fix or the hack until a more permanent solution can be found.

Comment 123

13 years ago
Why use the hack when you can use a simple solution that fixes the problem for
99% of people with zero risk. How long would it take for a reviewer(not saying
any names) to slap on the patch, verify that it works and give a thumbs up. It's
not like this is a major patch that requires thorough testing... Anyways, sorry
for the bugspam, I'm signing out of this bug for good.

Comment 124

13 years ago
(In reply to comment #121)
> How many people do you know use extra large fonts? Better yet, what's the global
> percentage of people who do use extra large fonts, to large fonts? I'd say that
> if someone can't see their screen well, they probably would change their screen
> resolution as they most likely would also have trouble seeing images and such.
> 

In the long run, as pixels become smaller (as they should) then people will need
to scale up font sizes up, and (especially on LCDs) people should not be
lowering their resolution because that would decrease smoothness of the fonts,
make it so large images don't fit anymore, and reduce the sharpness of vector
images (therefore eliminating the benefits of higher resolutions).  People will
also likely take advantage of greater resolution and start working more and more
with high resolution images so that they will look better as well. 

I'm not saying what to do about the patch, but I am pointing out an error in
what you said. 

Yes, the percentage is small, but computers are *not* going to stay at 800x600
(or are you thinking 1024x768?) forever -- pixels will continue to get closer
together and smaller at the same time, as well as (most, except for laptops)
displays getting bigger.
(Assignee)

Comment 125

13 years ago
After exploring many more options, including <html:div>, there just doesn't seem
to be any other way but the js hack. <html:div> is my best hope, but it will not
allow copying/pasting, or any selection. If I'm wrong in there not being any
other element other than <textbox> that will allow copying of its innerHTML (the
text), then please let me know. Other than that, the css fix is the only
plausible solution from my POV.
*** Bug 291007 has been marked as a duplicate of this bug. ***
*** Bug 301040 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 128

13 years ago
Created attachment 189657 [details] [diff] [review]
cleanup

Just cleaning up a few things, like style attributes and the <html:iframe>.
Still holds same css fix (which I'm assuming is what'll be applied).
Attachment #188060 - Attachment is obsolete: true
Attachment #189657 - Flags: review?(mconnor)
(Assignee)

Updated

13 years ago
Attachment #188060 - Flags: review?(mconnor)
*** Bug 309174 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Flags: blocking-aviary2.0?
Flags: blocking-aviary1.0.8?
Flags: blocking-aviary2.0?
Flags: blocking-aviary1.0.8?

Updated

13 years ago
Attachment #181682 - Flags: review?(mconnor)

Updated

13 years ago
Attachment #183460 - Flags: review?(mconnor)

Comment 130

13 years ago
Comment on attachment 189657 [details] [diff] [review]
cleanup

Clearing the last of the obsolete review requests.
Attachment #189657 - Flags: review?(mconnor)
(Assignee)

Comment 131

13 years ago
Comment on attachment 189657 [details] [diff] [review]
cleanup

Still applies cleanly for me. Re-requesting
Attachment #189657 - Flags: review?(mconnor)
indeed. still applies. i have it applied to my 2005100706 trunk build at this
moment.
Comment on attachment 144455 [details]
Screenshot illustrating bug

This screenshot no longer represents the current non-subtle effects. Nice job,
though.
Attachment #144455 - Attachment is obsolete: true
Flags: blocking1.8rc1?
(Reporter)

Comment 134

13 years ago
(In reply to comment #133)
> (From update of attachment 144455 [details])
> This screenshot no longer represents the current non-subtle effects.

Eh? Mine still looks *exactly* like this (without the patch, with a current
nightly).
without the patch, the bottom of the user agent is cut off. if u click and drag
down, ull notice the user agent shift up a little bit. this fixes that. it used
to be worse.

Updated

13 years ago
Flags: blocking1.8rc1? → blocking1.8rc1-
(In reply to comment #135)
> without the patch, the bottom of the user agent is cut off. if u click and drag
> down, ull notice the user agent shift up a little bit. this fixes that. it used
> to be worse.

For me--Windows XP, normal size fonts--the UA wraps to a third line so I see no
Firefox version information at all. The UA area is scrollable, but without any
scrollbars anyone with a system like mine won't know to scroll it.
it doesnt wrap to a third line, but it is cut off some, for me. try applying the
patch. it should allow more room. if it still needs scrolling, it should have
scrollbars.
(Assignee)

Comment 138

13 years ago
Comment on attachment 189657 [details] [diff] [review]
cleanup

Let's see if a dev can at least acknowledge this is a very safe, working patch
:)
Attachment #189657 - Flags: superreview?(dveditz)
Comment on attachment 189657 [details] [diff] [review]
cleanup

This patch works great for me. Still wraps to three lines with "Firefox/1.4.1"
(only two in 1.4) but all three are shown.

This is more of a symbolic sr=, in browser you need only a module owner r= (and
must have that r=).
Attachment #189657 - Flags: superreview+

Updated

13 years ago
Attachment #189657 - Flags: superreview?(dveditz)
Attachment #189657 - Flags: review?(mconnor)
Attachment #189657 - Flags: review+

Comment 140

13 years ago
This patch is not likely to break anything. I have been building my "amano"
builds with this and with all prior patches since FX 1.0 and no regression has
shown up.

So please ask for the approval for RC1 now. It is already late in the game. Aaron?

Comment 141

13 years ago
Comment on attachment 189657 [details] [diff] [review]
cleanup

Asking for approval for RC1 since a few people have said and I can confirm no
regressions have been introduced by this low risk patch.
Attachment #189657 - Flags: approval1.8rc1?
Assignee: nobody → dveditz

Updated

13 years ago
Attachment #189657 - Flags: approval1.8rc1? → approval1.8rc1+
(Assignee)

Updated

13 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

13 years ago
Assignee: dveditz → tonglebeak
Status: ASSIGNED → NEW
Fix checked into trunk and 1.8 branch
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Keywords: fixed1.8
Resolution: --- → FIXED
after over a year struggling, we can finally lay this one to rest.

Comment 144

13 years ago
(In reply to comment #142)
> Fix checked into trunk and 1.8 branch

So, I'd assume that it will be available as part of the 20051012 nightly?
I had only been seeing this on Linux, But it looks good with a branch build from
1013
Keywords: fixed1.8 → verified1.8

Comment 146

13 years ago
It's almost perfect; still scrolls about 1 or 2 px.  Otherwise, yes, working
quite fine.

Mozilla/5.0 (X11; U; Linux i686; en-CA; rv:1.9a1) Gecko/20051013 Firefox/1.6a1
ID:2005101304

Comment 147

13 years ago
Created attachment 200515 [details]
Screenshot of last patch.

As I said, this bug is still prominent, don't know why it's marked as fixed.  Attaching a screenshot of said problem, although this might have to do with another bug such as Bug 283697, although there might be some super-bug that deals with "window sizes calculated incorrectly for certain themes", but I can't find that bug if it exists at the moment.  If this is due to that, I'd suggest that we just re-open this, stick a dependson flag for that bug, and have this probably be fixed with that fix.

Comment 148

13 years ago
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051020 Firefox/1.6a1

Status: RESOLVED -> REOPENED
Resolution: FIXED -> ---

I still see this too. It's better, but I see a similar result to attachment 200515 [details].
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 149

13 years ago
WFM

Comment 150

13 years ago
(In reply to comment #149)
> WFM
> 

OS/Build/DPI/etc?

Comment 151

13 years ago
(In reply to comment #150)
> (In reply to comment #149)
> > WFM
> > 
> 
> OS/Build/DPI/etc?
> 

Win XP, Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051023 Firefox/1.5 ID:2005102310, 96dpi, 1152x864

Comment 152

13 years ago
Apparently this bug is only "fixed" for the Luna theme or something.  I think Firefox or the Core needs better support for the WM-supplied padding values and whatnot, regardless of OS.
(In reply to comment #152)
> Apparently this bug is only "fixed" for the Luna theme or something.
this works on classic. it works for me on windows xp, 1024x768 at 96dpi. this patch works on at atleast:
800x600
1024x768
1280x1024
96dpi
normal sized text
large text

things that are still broken:
120dpi
extra large text
apparently linux (linux ua is longer than windows, thats the only reason i see for it not working on linux)

all of the patches between "patch to support any legit useragent" and "fixed a whitespace problem, changed measuring function name" use javascript to make the about box big enough for whatever useragent you have. we went back to the simple css fix because it was simpler. Comment #113 is where i ask, and it is explained why we went with the css fix. i would be happy with the js solution. it works with 120dpi, extra large text, and the linux user agent. it fixes all the problems. not sure if its bit rotted, but if its not, then request review for the old patch.
(In reply to comment #153)
> apparently linux (linux ua is longer than windows, thats the only reason i see
> for it not working on linux)
sorry to bug spam, but the windows ua is longer than the linux ua. my mistake.

Comment 155

13 years ago
Created attachment 200924 [details]
Stretched About dialog - Linux.

Okay, this is an example of why using the definite dimensions is bad m'kay.  As you can see, the excess whitespace is not used, well, at all, but if you do stretch its width, it does indeed expand.  What I would propose is just having the about dialog be clear'd to the next line, and then have it stretch as far as it can go down without stretching the window (i.e. percentages instead of absolutes).  The height can be dynamically changed via a small JS hack that sets its height using the remaining space available.

Or even more simply put: make the damn about box a tad taller...

Comment 156

13 years ago
After messing around with the aboutDialog.css file, I have come to the conclusion that this bug has to be due to some XUL/CSS bug or some other layout-related bug.  The text box's dimensions are calculated incorrectly from the CSS attributes given.  I can't use the DOM Inspector to check it since it won't re-enable itself for me due to some other probable bug, but if someone else would like to check it out and let us know the results...

I'll see if I can make a testcase that demonstrates that better.

Comment 157

13 years ago
Created attachment 201262 [details] [diff] [review]
Patch that doesn't waste as much padding/margins for userAgent.

Basically, I swapped the margins and removed excess padding.  The userAgent still lines up correctly, but now it fits within the dialog without scrolling.  This is mainly to address the odd issue in the Linux build, so I'll need someone to test out the patch (it was made with "diff", so just use "patch") on win32 and mac and such.
Attachment #201262 - Flags: review?

Comment 158

13 years ago
Created attachment 201263 [details]
About dialog with previous patch.

Here's a screenshot of the patch in Linux.
Attachment #200515 - Attachment is obsolete: true
Just a small note for Matt: if you open the DOM Inspector before the about box, it'll function perfectly.

I'd help with this, but I'm running at a non-standard DPI, so window dimensions are always wrong for me.

Updated

13 years ago
Attachment #201262 - Flags: review?

Updated

13 years ago
Attachment #201262 - Attachment is obsolete: true

Comment 160

13 years ago
Created attachment 201266 [details] [diff] [review]
Better patch of previous with extra cvs diff info included.

Just noticed an alignment problem, fixed it with this patch.  This also has the cvs diff header info, so now you can diff it with the source a bit easier.
Attachment #201263 - Attachment is obsolete: true
Attachment #201266 - Flags: review?

Updated

13 years ago
Attachment #201266 - Flags: review?
Attachment #201266 - Flags: review+
Attachment #201266 - Flags: approval1.8rc2?

Comment 161

13 years ago
Comment on attachment 201266 [details] [diff] [review]
Better patch of previous with extra cvs diff info included.

Er er ee oo, how was I able to grant myself a review and whatnot?  I'm not a developer...

I know, I'll ask the guy who has better things to do than review a CSS patch!  If someone else would be better to ask for review, let me know.
Attachment #201266 - Flags: review+ → review?(mconnor)

Comment 162

13 years ago
Created attachment 201816 [details] [diff] [review]
patch to improve status quo for 1.5 release, not ultimate fix for trunk

Tested in 1.5rc1:
win32 1024x768 96 DPI
OS/2 1280x960 120 DPI
Linux 1792x1344 160 DPI

I couldn't find out what is responsible for the height of #userAgent, so I simply gave it a minimum to get rid of the scroll at high resolutions. Also, as you can see from before & after screenshots coming up, the right margin now is as little as literal 0, so I added some. This is much better than what we have now.
Attachment #201816 - Flags: superreview?
Attachment #201816 - Flags: review?

Updated

13 years ago
Attachment #201816 - Flags: superreview?(mconnor)
Attachment #201816 - Flags: superreview?
Attachment #201816 - Flags: review?(mconnor)
Attachment #201816 - Flags: review?

Comment 163

13 years ago
Created attachment 201817 [details]
screenshot Linux 1792x1344 160 DPI 1.5rc1 unpatched

Comment 164

13 years ago
Created attachment 201818 [details]
screenshot Linux 1792x1344 160 DPI 1.5rc1 with attachment 201816 [details] [diff] [review] applied

Comment 165

13 years ago
Created attachment 201819 [details]
screenshot win32 1024x768 96 DPI 1.5rc1 with attachment 201816 [details] [diff] [review] applied

Comment 166

13 years ago
Created attachment 201820 [details]
screenshot OS/2 1280x960 120 DPI 1.5rc1 with attachment 201816 [details] [diff] [review] applied

Comment 167

13 years ago
Created attachment 201821 [details]
screenshot OS/2 1280x960 120 DPI 1.5rc1 unpatched

previous fix did not fix OS/2

Comment 168

13 years ago
Approval should be requested once a patch has the necessary reviews I think. I also do not think this will go in on branch as it's a very trivial problem, and it's very, very late. Also, why in attachment 201820 [details] has the word 'Company' moved? And can you provide a "screenshot win32 1024x768 96 DPI 1.5rc1 unpatched" like you have for Linux and OS/2 for comparison please? It looks as if there is now a large gap in the win32 version.
Comment on attachment 201266 [details] [diff] [review]
Better patch of previous with extra cvs diff info included.

Its far too late for something this low-impact, especially when there's no clear consensus about what's right.
Attachment #201266 - Flags: approval1.8rc2?

Comment 170

13 years ago
Created attachment 201867 [details]
screenshot win32 1024x768 96 DPI 1.5rc1 unpatched

I didn't attach an unpatched shot of 1024x768 96 DPI because I figured that's the settings combination over half the planet was already using, and therefore superfluous. :-) If anyone wants more screenshots, I can supply just about any OS, resolution, & DPI combination anyone likes, as long as they don't require it be done on a Mac or PDA.

Company moved because I changed the margin to nonzero so that no text would ever touch the edge as in attachment 201817 [details]. Looks like that word came up about 1px shy of fitting where it was.

The best patch would involve someone figuring out why #userAgent without an explicit height set is always too short for 4 lines, and often too short for three lines, and removing that artificial constraint.

I don't understand why "late" would be reason to reject a "low-impact" polish patch. Improved polish is something people expect from .x version upgrades.

Comment 171

13 years ago
(In reply to comment #169)
> (From update of attachment 201266 [details] [diff] [review] [edit])
> Its far too late for something this low-impact, especially when there's no
> clear consensus about what's right.
> 

So we can't just stick with a CSS patch at this time?

I wonder if there's some core-level bug that's causing the textbox to be that way, or maybe it's a limitation in XUL that needs to be addressed.
Attachment #201816 - Flags: superreview?(mconnor)
Comment on attachment 201816 [details] [diff] [review]
patch to improve status quo for 1.5 release, not ultimate fix for trunk

not really useful at this point.  There's talk of leaving the UA for about: and cleaning this up a bit more
Attachment #201816 - Flags: review?(mconnor) → review-

Comment 173

13 years ago
Comment on attachment 201266 [details] [diff] [review]
Better patch of previous with extra cvs diff info included.

1.5.0.1rc2 @ 160DPI looks just like https://bugzilla.mozilla.org/attachment.cgi?id=201817 so this patch would, as before, give the upcoming release, improved polish.

Updated

13 years ago
Attachment #201816 - Flags: review- → review?(mconnor)
Comment on attachment 201816 [details] [diff] [review]
patch to improve status quo for 1.5 release, not ultimate fix for trunk

polish fixes aren't in scope for 1.5.0.x
Attachment #201816 - Flags: review?(mconnor) → review-

Updated

13 years ago
Attachment #201266 - Flags: review?(mconnor)
(Reporter)

Comment 175

12 years ago
This looks fixed to me now. Looks perfect on branch and trunk with Windows on Normal or Large fonts--accommodating a 3-line UA string just fine. Extra Large fonts provides a scrollbar to view the whole 4-line string, which is fine with me.
Status: REOPENED → RESOLVED
Last Resolved: 13 years ago12 years ago
Resolution: --- → FIXED

Comment 176

12 years ago
Nothing's changed since I created attachment 201817 [details]. 1.5.0.5 looks exactly the same. The iframe should be sized in em as in attachment 201816 [details] [diff] [review].
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to comment #176)
> Nothing's changed since I created attachment 201817 [details] [edit]. 1.5.0.5 looks exactly the
> same. The iframe should be sized in em as in attachment 201816 [details] [diff] [review] [edit].

Did you even read comment #174?

Comment 178

12 years ago
Fixed for me in Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1b1) Gecko/20060710 Firefox/2.0b1

I would mark as fixed.

Comment 179

12 years ago
Long time ago. All that means is the current status seems to be wontfix. The string is still not entirely displayed, making the about dialog look to high DPI users like it was designed by windoz for windoz and no one else matters. There's no good reason for that space to have a scrollbar on any but windoz systems, where everyone's used to riduculously short list boxes.
This is as fixed as it will ever be.  Its a trivial problem displaying a string that most people don't care about or look at more than once.
Status: REOPENED → RESOLVED
Last Resolved: 12 years ago12 years ago
Resolution: --- → FIXED

Comment 181

12 years ago
I hope 2.0 final is a lot better than attachment 201817 [details] because that's what 2.0b2 looks like.

Comment 182

12 years ago
Created attachment 243376 [details]
screenshot 2.0 on Linux 1600x1200x144DPI

Definitely not fixed.

Updated

12 years ago
Status: RESOLVED → VERIFIED

Updated

12 years ago
Status: VERIFIED → REOPENED
Resolution: FIXED → ---

Comment 183

12 years ago
Not only is only about half the UA string shown, the page title doesn't even fit the titlebar. This is very unpolished.
File a new bug, with steps to reproduce and your system config. This bug has outlived it's usefulness.
Status: REOPENED → RESOLVED
Last Resolved: 12 years ago12 years ago
Resolution: --- → FIXED

Comment 185

12 years ago
Steps to reproduce have not changed since this bug was opened. Simply use a DPI more than nominally higher than 96, and open the about dialog. 120, 144 and 192 are all bad.
Summary: User Agent string in the About Firefox dialog is cut off at the bottom → Firefox needs a competently designed about window.
(In reply to comment #185)
> Steps to reproduce have not changed since this bug was opened. Simply use a DPI
> more than nominally higher than 96, and open the about dialog. 120, 144 and 192
> are all bad.

This bug as originally filed wasn't about users who use abnormal DPI settings. Please file a new bug about that, if one isn't already filed.
Status: RESOLVED → VERIFIED
Summary: Firefox needs a competently designed about window. → User Agent string in the About Firefox dialog is cut off at the bottom

Comment 187

12 years ago
Comment 0 was simply an incomplete description of the problem. If 1-2px are cut off at the bottom when only 2 lines are showing, then by definition the third and subsequent lines are missing. The dialog was incompetently designed when this bug was filed, and remains so now.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(In reply to comment #187)
> Comment 0 was simply an incomplete description of the problem.

No, it wasn't. This bug has now been fixed for the majority of cases. Please don't reopen this bug. Find me on IRC if you want to discuss this further.
Status: REOPENED → RESOLVED
Last Resolved: 12 years ago12 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED

Comment 189

12 years ago
I have ben following this bug for sometime. I think it was decided that this bug would only fixe the situation for normal fonts. People who want a solution for personal configuration should open an another bug. This bug is fixed ! Before reopening please obtain somekind of consensus by discusion.
Status: VERIFIED → RESOLVED
Last Resolved: 12 years ago12 years ago
See comment 180

Felix, you know better than to pingpong bugs because you disagree with the resolution :P
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.