Closed Bug 386759 Opened 14 years ago Closed 14 years ago

Kerning disabled in new location bar on hover (text moves or shifts when mouse moves over it)

Categories

(Core :: Layout, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: dao, Assigned: roc)

References

()

Details

(Keywords: testcase, Whiteboard: [cannot reproduce][dbaron-1.9:RuCt])

Attachments

(7 files, 4 obsolete files)

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.
(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?
I'm pretty sure that this is because kerning is being disabled, changing the summary. Someone smack me if I'm wrong.
Summary: text occasionally moves when moving the mouse over the address → Kerning disabled in new location bar on hover (text moves or shifts when mouse moves over it)
Depends on: 387969
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?
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.
Status: NEW → RESOLVED
Closed: 14 years ago
Depends on: 387703
Resolution: --- → WORKSFORME
We will reenable kerning in chrome after my text-rendering patch lands.
With checkin of bug 387969, this happens again. 
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Assignee: nobody → dao
Status: REOPENED → ASSIGNED
Attachment #274034 - Flags: review?(gavin.sharp)
Please pick one patch for review. I can also file a new bug for the cleanup.
Attachment #274035 - Flags: review?(gavin.sharp)
Blocks: 388371
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).
Flags: wanted1.8.0.x-
Attachment #274034 - Flags: review?(gavin.sharp)
Attachment #274035 - Flags: review?(gavin.sharp)
Attached file testcase
Keywords: testcase
Attachment #274035 - Attachment is obsolete: true
Assignee: dao → nobody
Status: ASSIGNED → NEW
Component: Location Bar and Autocomplete → Layout
Product: Firefox → Core
QA Contact: location.bar → layout
Flags: blocking1.9?
Attachment #274034 - Attachment is obsolete: true
Flags: in-testsuite?
Attached patch fix (obsolete) — Splinter Review
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.
Assignee: nobody → roc
Status: NEW → ASSIGNED
Attachment #275348 - Flags: review?
Attachment #275348 - Flags: review? → review?(mconnor)
Comment on attachment 275348 [details] [diff] [review]
fix

wrong patch sorry
Attachment #275348 - Attachment is obsolete: true
Attachment #275348 - Flags: review?(mconnor)
roc, your patch doesn't seem to fix the test case or the Location Bar for me.
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...
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.)
(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).
Dao, which text has kerning and which doesn't?
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.
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.
> 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?
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?
(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.
Versions of pango, freetype, and DejaVu may be relevant.
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).
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.
Attached image what i see in testcase
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.
I see this bug all the time; I could probably debug stuff for you if I have time.
Flags: blocking1.9? → blocking1.9+
(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.
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
Attachment #275357 - Flags: review?(mconnor) → review+
I checked in the change to forms.css. Let's see if that affects performance. I'll check in the xul.css change separately.
That didn't seem to cause any performance issues. I'll check in the xul.css change later when the tree is quiet.
Checked in the xul.css patch. We'll see what happens to performance now.
Performance looks fine.

So, who can reproduce this now?
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.
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
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.)
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?
Whiteboard: [cannot reproduce]
Whiteboard: [cannot reproduce] → [cannot reproduce][dbaron-1.9:RuCt]
The formatted-url view will most likely be removed from the Location Bar binding, so this won't be an issue anymore.
Testcase works for me with Ubuntu 7.10. Let's resolve this bug.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.