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

RESOLVED FIXED

Status

()

Core
Layout
RESOLVED FIXED
11 years ago
3 years ago

People

(Reporter: dao, Assigned: roc)

Tracking

({testcase})

Trunk
x86
Linux
testcase
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 +
wanted1.8.0.x -

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(7 attachments, 4 obsolete attachments)

(Reporter)

Description

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

Comment 1

11 years ago
Created attachment 270765 [details]
example: ftp.mozilla.org, formatted view
(Reporter)

Comment 2

11 years ago
Created attachment 270766 [details]
example: ftp.mozilla.org, editable view
(Reporter)

Comment 3

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

Comment 4

11 years ago
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)
(Reporter)

Updated

11 years ago
Depends on: 387969

Comment 6

11 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?
(Reporter)

Comment 7

11 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.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Depends on: 387703
Resolution: --- → WORKSFORME
We will reenable kerning in chrome after my text-rendering patch lands.

Comment 9

11 years ago
With checkin of bug 387969, this happens again. 
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(Reporter)

Comment 10

11 years ago
Created attachment 274034 [details] [diff] [review]
enable kerning for the input field
Assignee: nobody → dao
Status: REOPENED → ASSIGNED
Attachment #274034 - Flags: review?(gavin.sharp)
(Reporter)

Comment 11

11 years ago
Created attachment 274035 [details] [diff] [review]
enable kerning for the input field + drive-by cleanup

Please pick one patch for review. I can also file a new bug for the cleanup.
Attachment #274035 - Flags: review?(gavin.sharp)
(Reporter)

Updated

11 years ago
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-
(Reporter)

Updated

11 years ago
Attachment #274034 - Flags: review?(gavin.sharp)
(Reporter)

Updated

11 years ago
Attachment #274035 - Flags: review?(gavin.sharp)
(Reporter)

Comment 13

11 years ago
Created attachment 274070 [details]
testcase
(Reporter)

Updated

11 years ago
Keywords: testcase
(Reporter)

Updated

11 years ago
Attachment #274035 - Attachment is obsolete: true
(Reporter)

Updated

11 years ago
Assignee: dao → nobody
Status: ASSIGNED → NEW
(Reporter)

Updated

11 years ago
Component: Location Bar and Autocomplete → Layout
Product: Firefox → Core
QA Contact: location.bar → layout
(Reporter)

Updated

11 years ago
Flags: blocking1.9?
(Reporter)

Updated

11 years ago
Attachment #274034 - Attachment is obsolete: true
(Reporter)

Updated

11 years ago
Flags: in-testsuite?
Created attachment 275348 [details] [diff] [review]
fix

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)
Created attachment 275353 [details] [diff] [review]
correct patch to set text-rendering:optimizeLegibility for XUL and HTML inputs

This is the right patch
Attachment #275353 - Flags: review?(mconnor)
Created attachment 275357 [details] [diff] [review]
sigh --- another iteration, setting quality for all XUL root elements this time
Attachment #275353 - Attachment is obsolete: true
Attachment #275357 - Flags: review?(mconnor)
Attachment #275353 - Flags: review?(mconnor)
(Reporter)

Comment 18

11 years ago
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.)
(Reporter)

Comment 21

11 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).
Duplicate of this bug: 391441
Dao, which text has kerning and which doesn't?
(Reporter)

Comment 24

11 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.
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?
Created attachment 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?
What do you expect?
(Reporter)

Comment 28

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

Comment 31

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

Comment 32

11 years ago
Created attachment 278208 [details]
screenshot, testcase failing
Created attachment 278365 [details]
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+
(Reporter)

Comment 35

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

Comment 41

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

Comment 42

11 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
(Reporter)

Comment 43

11 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.)
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]
(Reporter)

Comment 45

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

Comment 46

10 years ago
Testcase works for me with Ubuntu 7.10. Let's resolve this bug.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago10 years ago
Resolution: --- → FIXED
(Reporter)

Updated

3 years ago
Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.