Dão Gottwald [:dao] Reporter
	Description • 17 years ago

I can easily reproduce this with hosts starting with www. In that case, I always see an extra pixel between "www" and the following dot when the Location bar switches to the editable mode.

I'm seeing this on Linux (Ubuntu Feisty) only.

	Dão Gottwald [:dao] Reporter
	Comment 3 • 17 years ago

(In reply to comment #0)
> I'm seeing this on Linux (Ubuntu Feisty) only.

But not with Firefox 2 using the Locationbar² extension.

Could that have something to do with roc's text rendering changes?

	dolphinling
	Comment 4 • 17 years ago

I'm pretty sure that this is because kerning is being disabled, changing the summary. Someone smack me if I'm wrong.

	Sylvain Pasche
	Comment 5 • 17 years ago

I don't see this issue on recent builds.

Regression range:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-07-16+04%3A00%3A00&maxdate=2007-07-17+05%3A00%3A00&cvsroot=%2Fcvsroot

Maybe bug 387703 fixed that.

	dolphinling
	Comment 6 • 17 years ago

Looks like it was fixed by disabling kerning entirely. Is that wanted? I thought chrome was supposed to always use pango (which does kerning, as opposed to the Xft fast path, which doesn't). 

Could it be that this bug is just being masked now? Should a separate "Kerning disabled entirely in location bar" bug be filed?

	Dão Gottwald [:dao] Reporter
	Comment 7 • 17 years ago

I don't know if kerning is now disabled or enabled entirely. Either way, if you think it's wrong, then yes, file a bug. This one can be closed as letters don't shift anymore.

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 8 • 17 years ago

We will reenable kerning in chrome after my text-rendering patch lands.

	dolphinling
	Comment 9 • 17 years ago

With checkin of bug 387969, this happens again. 

	Dão Gottwald [:dao] Reporter
	Comment 11 • 17 years ago

Please pick one patch for review. I can also file a new bug for the cleanup.

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 12 • 17 years ago

I plan to make all textfields use text-rendering:optimizeLegiblity (which is what you want here), so this won't be necessary (unless you need a fix for M7, which I don't think you do).

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 14 • 17 years ago

Dao, can you verify that this patch fixes the bug?

This is what I said I want to do: make regular XUL documents and also HTML leaf form elements use high-quality rendering by default.

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 15 • 17 years ago

Comment on attachment 275348 [details] [diff] [review]
fix

wrong patch sorry

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 16 • 17 years ago

This is the right patch

	Dão Gottwald [:dao] Reporter
	Comment 18 • 17 years ago

roc, your patch doesn't seem to fix the test case or the Location Bar for me.

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 19 • 17 years ago

Karl, can you apply the patch here and figure out what's going on? I've verified that the HTML INPUT and the XUL elements that cover it are all text-rendering:optimizeLegibility. Thanks...

	Karl Tomlinson (:karlt)
	Comment 20 • 17 years ago

Rob's patch fixed the problem I could reproduce with http://www.mozilla.org/ in Bitstream Vera Sans.  (Arial didn't show the problem.)

I wasn't able to reproduce any problem in the testcase in comment 13.

Dão: What font are you using?  (The default font from preferences.)

	Dão Gottwald [:dao] Reporter
	Comment 21 • 17 years ago

(In reply to comment #19)
> I've
> verified that the HTML INPUT and the XUL elements that cover it are all
> text-rendering:optimizeLegibility.

I did verify that, too, via DOM Inspector.

(In reply to comment #20)
> Rob's patch fixed the problem I could reproduce with http://www.mozilla.org/ in
> Bitstream Vera Sans.  (Arial didn't show the problem.)
> 
> I wasn't able to reproduce any problem in the testcase in comment 13.
> 
> Dão: What font are you using?  (The default font from preferences.)

I think it was Bitstream Vera Sans, but I have to double-check. With regards to http://www.mozilla.org/projects/firefox/3.0a8pre/releasenotes/, I think things have improved a litte, but some letters were still shifted (either to the left or to the right, which made other letters stay still).

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 23 • 17 years ago

Dao, which text has kerning and which doesn't?

	Dão Gottwald [:dao] Reporter
	Comment 24 • 17 years ago

Ok ... the patch _does_ fix the urlbar, but only if the protocol is not hidden (e.g. browser.urlbar.hideProtocols != "http https"), which is basically what the testcase is about: setting width on a xul:label messes kerning up, even if width := boxObject.width.

My system font is not Bitstream Vera Sans but DeJaVu Sans (which looks almost identical). All works fine with Bitstream Vera Sans.

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 25 • 17 years ago

We should take this patch anyway, since it fixes things for Karl and is The Right Thing To Do. Then we can figure out what's wrong with DejaVu Sans.

	Karl Tomlinson (:karlt)
	Comment 26 • 17 years ago

> Ok ... the patch _does_ fix the urlbar, but only if the protocol is not hidden
> (e.g. browser.urlbar.hideProtocols != "http https"), which is basically what
> the testcase is about: setting width on a xul:label messes kerning up, even if
> width := boxObject.width.

Can you clarify for me, please: is the testcase behaving as expected for you with the patch?  I can't see any difference on clicking "switch" with "DejaVu Sans" in Preferences->Content.  What font do you have there?

	Karl Tomlinson (:karlt)
	Comment 27 • 17 years ago

I'm not sure what behaviour to expect with the protocol hidden.
The protocol returns in the editable view (so it can be editted).
I have DejaVu Sans as system font, and the path remains in the same place when changing view modes; only the hostname moves.
Is that what you see?
What do you expect?

	Dão Gottwald [:dao] Reporter
	Comment 28 • 17 years ago

(In reply to comment #26)
> > Ok ... the patch _does_ fix the urlbar, but only if the protocol is not hidden
> > (e.g. browser.urlbar.hideProtocols != "http https"), which is basically what
> > the testcase is about: setting width on a xul:label messes kerning up, even if
> > width := boxObject.width.
> 
> Can you clarify for me, please: is the testcase behaving as expected for you
> with the patch?

No, it fails.

> I can't see any difference on clicking "switch" with "DejaVu
> Sans" in Preferences->Content.  What font do you have there?

I was looking at and altering the OS settings, not Firefox->Preferences->Content. It said "Sans" (whatever that means), but I've also picked DejaVu Sans explicitly.

(In reply to comment #27)
> Created an attachment (id=277635) [details]
> urlbar with protocol hidden, formatted view
> 
> I'm not sure what behaviour to expect with the protocol hidden.
> The protocol returns in the editable view (so it can be editted).
> I have DejaVu Sans as system font, and the path remains in the same place when
> changing view modes; only the hostname moves.
> Is that what you see?

No, what I see is that the path moves.

I can take screenshots at the weekend. This shouldn't hold back the current patch, of course.

	Karl Tomlinson (:karlt)
	Comment 29 • 17 years ago

Versions of pango, freetype, and DejaVu may be relevant.

	Karl Tomlinson (:karlt)
	Comment 30 • 17 years ago

I have pango-1.16.4 freetype-2.3.5 dejavu-2.18-r1 on Gentoo, but what is more likely to be significant is:

Output from "xrdb -query | grep Xft" (hoping that is synced to gnome-properties if you are using that).  I have:
Xft.antialias:  1
Xft.dpi:        96.0
Xft.hinting:    1
Xft.hintstyle:  hintfull
Xft.rgba:       none

And do you have a size set for you system font in ~/.gtkrc-2.0 or some gnome settings manager.  I have the gtk default (unless Clearlooks changes that).

	Dão Gottwald [:dao] Reporter
	Comment 31 • 17 years ago

I have libpango1.0-0 1.16.2-0ubuntu1, libfreetype6 2.2.1-5ubuntu1.1 and ttf-dejavu 2.14-2.

Xft.antialias:  1
Xft.dpi:        96.000000
Xft.hinting:    1
Xft.hintstyle:  hintmedium
Xft.rgba:       none

I haven't touched any size settings. Gnome preferences say it's at 10.

	Karl Tomlinson (:karlt)
	Comment 33 • 17 years ago

I changed to "Xft.hintstyle: hintmedium" but had no success reproducing.
(My glyphs look very similar to yours but the spacing is different.)

I see in your screenshot is that "org" is the same in each of the centered hboxes (one of which has the width set), but differs in the enclosing hboxes.

	David Baron :dbaron:
	Comment 34 • 17 years ago

I see this bug all the time; I could probably debug stuff for you if I have time.

	Dão Gottwald [:dao] Reporter
	Comment 35 • 17 years ago

(In reply to comment #34)
> I see this bug all the time; I could probably debug stuff for you if I have
> time.

If the test case (attachment 274070 [details]) fails in your case (as in attachment 278208 [details]), debugging would probably help. If it doesn't fail, roc's patch should entirely fix the Location Bar on your system.

	Mike Connor [:mconnor]
	Comment 36 • 17 years ago

Comment on attachment 275357 [details] [diff] [review]
sigh --- another iteration, setting quality for all XUL root elements this time

r=me, sorry for the delay

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 37 • 17 years ago

I checked in the change to forms.css. Let's see if that affects performance. I'll check in the xul.css change separately.

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 38 • 17 years ago

That didn't seem to cause any performance issues. I'll check in the xul.css change later when the tree is quiet.

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 39 • 17 years ago

Checked in the xul.css patch. We'll see what happens to performance now.

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 40 • 17 years ago

Performance looks fine.

So, who can reproduce this now?

	[:Aleksej]
	Comment 41 • 17 years ago

It doesn't move now (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a8pre) Gecko/2007091904 Minefield/3.0a8pre), though becomes gray for a moment when unhovered.

	Dão Gottwald [:dao] Reporter
	Comment 42 • 17 years ago

The testcase still fails over here.
And accordingly, some URLs (like the one in the URL field) move with browser.urlbar.hideProtocols = "http".

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a8pre) Gecko/2007092004 Minefield/3.0a8pre

	Dão Gottwald [:dao] Reporter
	Comment 43 • 17 years ago

So, I thought maybe turning kerning off altogether could solve the problem for me. But if I add text-rendering:optimizespeed to .formatted-url, the appearance doesn't change at all, even though the computed style reports the correct text-rendering value. That property appears to be completely effectless there.

Adding text-rendering:optimizespeed to .textbox-input does make an immediate difference (i.e. more movement, as it was before you've checked in the patch.)

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 44 • 17 years ago

XUL labels and other non-DOM-text-node drawing always use the high-quality path, they don't honor the text-rendering setting.

David, can you see the bug in the FF chrome or in the testcase?

	Dão Gottwald [:dao] Reporter
	Comment 45 • 17 years ago

The formatted-url view will most likely be removed from the Location Bar binding, so this won't be an issue anymore.

	Dão Gottwald [:dao] Reporter
	Comment 46 • 17 years ago

Testcase works for me with Ubuntu 7.10. Let's resolve this bug.