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

Status: VERIFIED FIXED

(Firefox :: General, defect, P5)

Description

[Greg Campbell]

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

[Bill Mason]

WFM 20040320 PC/WinXP

Comment 2

[Kevin Brosnan]

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

Comment 3

[Greg Campbell]

Attachment: Screenshot illustrating bug

Comment 4

[Kevin Brosnan]

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

Comment 5

[Greg Campbell]

Bug 240349 has a screenshot from linux with the text cut off significantly more
than my screenshot from WinXP. OS->All.

Comment 6

[Greg Campbell]

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?

Comment 7

[Andreas Kunz]

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

Comment 8

[Sean Umphlet (nosebleed)]

Confirming.

I am seeeing this on firefox 20040521 on debian sid.

Comment 9

[PikeUK]

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

Comment 10

[Aaron Peterson]

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

Comment 11

[PikeUK]

(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

[Aaron Peterson]

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..  

Comment 13

[Mike Connor [:mconnor]]

-ing will take patch

Comment 14

[Jeff Walden [:Waldo]]

Attachment: 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.

Comment 15

[Jeff Walden [:Waldo]]

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

Requesting review from mconnor...

Comment 16

[Tracy Walker [:tracy]]

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

Comment 17

[Jeff Walden [:Waldo]]

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...

Comment 18

[Greg Campbell]

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

[Francois Ingelrest]

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

[chris hofmann]

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

Comment 21

[chris hofmann]

think that we are going to be too overloaded to get to this for 1.0...  -minus
blocker nomination

Comment 22

[Felix Miata]

Attachment: screenshot

Truly pitiful that this wasn't fixed before 1.0.

Comment 23

[Bill Mason]

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

Comment 24

[amano]

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

[Frédéric Buclin]

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

Comment 26

[Bill Mason]

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

Comment 27

[amano]

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

Comment 28

[Mike Connor [:mconnor]]

blocking is "we won't ship with this" not an attention flag.

Comment 29

[Jo Hermans]

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

Comment 30

[José Jeria]

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

Comment 31

[Felix Miata]

Attachment: screenshot of 1.0.1 @ 120 DPI

shame, shame

Comment 32

[José Jeria]

(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

[David Tenser [:djst]]

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

Comment 34

[Grayson Mixon (ColdFusion650)]

theres already a patch for this. can someone review it and check it in?

Comment 35

[Sergey Sokoloff]

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/

Comment 36

[Grayson Mixon (ColdFusion650)]

i think it would just be better to check in the patch. i dont think i could
stand a communist about box.

Comment 37

[Steve England [:stevee]]

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.

Comment 38

[Grayson Mixon (ColdFusion650)]

it fixes it for everybody. its just that _nobody_ wants to check it in.

Comment 39

[Greg Campbell]

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.

Comment 40

[Bill Gianopoulos [:WG9s]]

(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

[amano]

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

Comment 42

[Tim Meader]

Attachment: 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.

Comment 43

[:Gavin Sharp [email: [e-mail]]]

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

Comment 44

[José Jeria]

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

Comment 45

[Joël Kuiper]

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

Comment 46

[Caleb]

(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

[Reuven Gonen]

(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.

Comment 48

[Bill Gianopoulos [:WG9s]]

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.

Comment 49

[Bill Gianopoulos [:WG9s]]

(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.

Comment 50

[Peter van der Woude [:Peter6]]

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

[mmortal03]

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

Comment 52

[Caleb]

(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.

Comment 53

[Greg Campbell]

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?

Comment 54

[Grey Nicholson (they/them)]

(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?

Comment 55

[Aaron Slunt]

Attachment: 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.

Comment 56

[Mike Connor [: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

Comment 57

[Tim Meader]

Attachment: Diff based on new submitted patch.

Here is a diff based on the new patch submitted earlier. Hope this is fine.

Comment 58

[Bill Gianopoulos [:WG9s]]

(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.

Comment 59

[PikeUK]

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.

Comment 60

[:Gavin Sharp [email: [e-mail]]]

[e-mail]: Please read comment 28.

Comment 61

[Grayson Mixon (ColdFusion650)]

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.

Comment 62

[:Gavin Sharp [email: [e-mail]]]

Attachment: Remove hardcoded height, adjust margin

Comment 63

[Grayson Mixon (ColdFusion650)]

what does adjusting the margin do? the extra line done at the bottom is still
there for me.

Comment 64

[Bill Gianopoulos [:WG9s]]

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;
}

Comment 65

[Bill Gianopoulos [:WG9s]]

(In reply to comment #64)
>   heigth: auto !important;

Hmm. think I need a spellchecker.

Obviously,height would work better here. :-)

Comment 66

[Caleb]

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.

Comment 67

[:Gavin Sharp [email: [e-mail]]]

Attachment: William's approach

Comment 68

[Caleb]

(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 :)

Comment 69

[:Gavin Sharp [email: [e-mail]]]

Please, stop requesting blocking status for such a minor detail. This is not
going to block any releases.

Comment 70

[Aaron Slunt]

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.

Comment 71

[Grayson Mixon (ColdFusion650)]

setting the height to auto, which is the current solution, would do the exact
same thing, just more simply.

Comment 72

[Greg Campbell]

Attachment: 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."

Comment 73

[Grayson Mixon (ColdFusion650)]

ok, ur right. go ahead and develope the patch and ill try it out.

Comment 74

[Greg Campbell]

(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.

Comment 75

[Aaron Slunt]

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.

Comment 76

[Aaron Slunt]

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.

Comment 77

[Aaron Slunt]

(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

[Jason Daly]

I have this problem with a default install of windows, no font changes. As
illustrated in the first screenshot. Really makes firefox look tacky.

Comment 79

[Grayson Mixon (ColdFusion650)]

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.

Comment 80

[Aaron Slunt]

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.

Comment 81

[Aaron Slunt]

Attachment: 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.

Comment 82

[Grayson Mixon (ColdFusion650)]

the patch shows up as jibberish.

Comment 83

[Aaron Slunt]

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

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

Comment 84

[Aaron Slunt]

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

changing mime-type

Comment 85

[Aaron Slunt]

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?

Comment 86

[Ryan VanderMeulen [:RyanVM]]

(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

Comment 87

[Aaron Slunt]

I did create diffs, I just thought I had to pack them all into one file. Are you
saying to submit all three separately?

Comment 88

[:Gavin Sharp [email: [e-mail]]]

(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.

Comment 89

[Ryan VanderMeulen [:RyanVM]]

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.

Comment 90

[Aaron Slunt]

Attachment: patch to support legit useragents

Sorry about the mess guys.

Comment 91

[Ryan VanderMeulen [:RyanVM]]

Attachment: Fixed version of previous patch

This fixes the issues with applying the patch to the source tree.

Comment 92

[Ryan VanderMeulen [:RyanVM]]

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.

Comment 93

[Ryan VanderMeulen [:RyanVM]]

Good news is that the patch appears to work.

Comment 94

[Ryan VanderMeulen [:RyanVM]]

(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

Comment 95

[Aaron Slunt]

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.

Comment 96

[Aaron Slunt]

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?

Comment 97

[Sergey Sokoloff]

any of the two

Comment 98

[Aaron Slunt]

Attachment: 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.

Comment 99

[Aaron Slunt]

Attachment: 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.

Comment 100

[Aaron Slunt]

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

Mr. Connor, your take on this?

Comment 101

[Jason Daly]

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

Comment 102

[Felix Miata]

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.

Comment 103

[Aaron Slunt]

Calm down, the patch is pending review.

Comment 104

[:Gavin Sharp [email: [e-mail]]]

Please stop asking for blocking status, this bug won't block any release.

Comment 105

[Grayson Mixon (ColdFusion650)]

why wont anyone review the patch?

Comment 106

[Michael Lefevre]

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.

Comment 107

[Aaron Slunt]

Has anyone else tested it, so I know if it's alright or if it needs work?

Comment 108

[Grayson Mixon (ColdFusion650)]

ive tested it and it needs work.

Comment 109

[Grayson Mixon (ColdFusion650)]

sorry, i meant to say that it wfm. disregard my previous comment.

Comment 110

[Matt]

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...

Comment 111

[Aaron Slunt]

Attachment: 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.

Comment 112

[Aaron Slunt]

Attachment: 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.

Comment 113

[Grayson Mixon (ColdFusion650)]

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.

Comment 114

[Aaron Slunt]

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.

Comment 115

[Grayson Mixon (ColdFusion650)]

true. ok, this patch has my blessing. hopefully, this will get checked in in
time for 1.1a2.

Comment 116

[Jason Daly]

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!!

Comment 117

[Mike Connor [:mconnor]]

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/

Comment 118

[Grayson Mixon (ColdFusion650)]

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.

Comment 119

[Greg Campbell]

Attachment: 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.

Comment 120

[Grayson Mixon (ColdFusion650)]

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.

Comment 121

[Aaron Slunt]

(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.

Comment 122

[Grayson Mixon (ColdFusion650)]

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

[Jason Daly]

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

[Zachariah]

(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.

Comment 125

[Aaron Slunt]

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.

Comment 126

[Mike Connor [:mconnor]]

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

Comment 127

[:Gavin Sharp [email: [e-mail]]]

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

Comment 128

[Aaron Slunt]

Attachment: 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).

Comment 129

[:Gavin Sharp [email: [e-mail]]]

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

Comment 130

[Adam Guthrie]

Comment on attachment 189657 [details] [diff] [review]
cleanup

Clearing the last of the obsolete review requests.

Comment 131

[Aaron Slunt]

Comment on attachment 189657 [details] [diff] [review]
cleanup

Still applies cleanly for me. Re-requesting

Comment 132

[Grayson Mixon (ColdFusion650)]

indeed. still applies. i have it applied to my 2005100706 trunk build at this
moment.

Comment 133

[Daniel Veditz [:dveditz]]

Comment on attachment 144455 [details]
Screenshot illustrating bug

This screenshot no longer represents the current non-subtle effects. Nice job,
though.

Comment 134

[Greg Campbell]

(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).

Comment 135

[Grayson Mixon (ColdFusion650)]

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.

Comment 136

[Daniel Veditz [:dveditz]]

(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.

Comment 137

[Grayson Mixon (ColdFusion650)]

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.

Comment 138

[Aaron Slunt]

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
:)

Comment 139

[Daniel Veditz [: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=).

Comment 140

[amano]

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

[u88484]

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.

Comment 142

[Daniel Veditz [:dveditz]]

Fix checked into trunk and 1.8 branch

Comment 143

[Grayson Mixon (ColdFusion650)]

after over a year struggling, we can finally lay this one to rest.

Comment 144

[Matt]

(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?

Comment 145

[Tracy Walker [:tracy]]

I had only been seeing this on Linux, But it looks good with a branch build from
1013

Comment 146

[Matt]

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

[Matt]

Attachment: 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

[Daniel C]

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].

Comment 149

[Shayne Jewers]

WFM

Comment 150

[Matt]

(In reply to comment #149)
> WFM
> 

OS/Build/DPI/etc?

Comment 151

[Shayne Jewers]

(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

[Matt]

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.

Comment 153

[Grayson Mixon (ColdFusion650)]

(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.

Comment 154

[Grayson Mixon (ColdFusion650)]

(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

[Matt]

Attachment: 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

[Matt]

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

[Matt]

Attachment: 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.

Comment 158

[Matt]

Attachment: About dialog with previous patch.

Here's a screenshot of the patch in Linux.

Comment 159

[ignazvonstraubing+bugzilla]

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.

Comment 160

[Matt]

Attachment: 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.

Comment 161

[Matt]

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.

Comment 162

[Felix Miata]

Attachment: 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.

Comment 163

[Felix Miata]

Attachment: screenshot Linux 1792x1344 160 DPI 1.5rc1 unpatched

Comment 164

[Felix Miata]

Attachment: screenshot Linux 1792x1344 160 DPI 1.5rc1 with attachment 201816 applied

Comment 165

[Felix Miata]

Attachment: screenshot win32 1024x768 96 DPI 1.5rc1 with attachment 201816 applied

Comment 166

[Felix Miata]

Attachment: screenshot OS/2 1280x960 120 DPI 1.5rc1 with attachment 201816 applied

Comment 167

[Felix Miata]

Attachment: screenshot OS/2 1280x960 120 DPI 1.5rc1 unpatched

previous fix did not fix OS/2

Comment 168

[Daniel C]

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 169

[Mike Connor [:mconnor]]

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.

Comment 170

[Felix Miata]

Attachment: 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

[Matt]

(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.

Comment 172

[Mike Connor [: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

Comment 173

[Felix Miata]

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.

Comment 174

[Mike Connor [: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

Comment 175

[Greg Campbell]

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.

Comment 176

[Felix Miata]

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].

Comment 177

[Reed Loden [:reed]]

(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

[Gabriel Chadwick]

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

[Felix Miata]

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.

Comment 180

[Mike Connor [:mconnor]]

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.

Comment 181

[Felix Miata]

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

Comment 182

[Felix Miata]

Attachment: screenshot 2.0 on Linux 1600x1200x144DPI

Definitely not fixed.

Comment 183

[Felix Miata]

Not only is only about half the UA string shown, the page title doesn't even fit the titlebar. This is very unpolished.

Comment 184

[:Gavin Sharp [email: [e-mail]]]

File a new bug, with steps to reproduce and your system config. This bug has outlived it's usefulness.

Comment 185

[Felix Miata]

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.

Comment 186

[:Gavin Sharp [email: [e-mail]]]

(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.

Comment 187

[Felix Miata]

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.

Comment 188

[:Gavin Sharp [email: [e-mail]]]

(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.

Comment 189

[Gabriel Chadwick]

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.

Comment 190

[Mike Connor [:mconnor]]

See comment 180

Felix, you know better than to pingpong bugs because you disagree with the resolution :P