Plain text in WWW pages now appears to be double-spaced? (line height is double, too tall, newlines, blockquote, pre)

VERIFIED FIXED in Firefox 12

Status

()

Core
Layout: Text
VERIFIED FIXED
6 years ago
5 years ago

People

(Reporter: M ODonnell, Assigned: jfkthame)

Tracking

({regression})

Trunk
mozilla12
x86
Linux
regression
Points:
---

Firefox Tracking Flags

(firefox12+ verified)

Details

(Whiteboard: [qa!])

Attachments

(5 attachments)

(Reporter)

Description

6 years ago
User Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0a1) Gecko/20120107 Firefox/12.0a1
Build ID: 20120107031040

Steps to reproduce:

Allowed my version of "nightly" to update itself to 12.0a1 (2012-01-07) and now plain text in WWW pages now appears to be double-spaced?


Actual results:

Blank lines appear between each text line.


Expected results:

No blank lines should appear.

Comment 1

6 years ago
Confirmed on Debian  6.0.3 GNOME 2.30.2.
http://hg.mozilla.org/mozilla-central/rev/5a446202be5f
Mozilla/5.0 (X11; Linux i686; rv:12.0a1) Gecko/20120107 Firefox/12.0a1 ID:20120107031040

Regression window(m-c)
Works:
http://hg.mozilla.org/mozilla-central/rev/c7e27452a143
Mozilla/5.0 (X11; Linux i686; rv:12.0a1) Gecko/20120106 Firefox/12.0a1 ID:20120106031054
Fails:
http://hg.mozilla.org/mozilla-central/rev/fcc32e70c95f
Mozilla/5.0 (X11; Linux i686; rv:12.0a1) Gecko/20120106 Firefox/12.0a1 ID:20120106042423
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c7e27452a143&tochange=fcc32e70c95f


Regression window(m-i)
Works:
http://hg.mozilla.org/integration/mozilla-inbound/rev/511078d51f71
Mozilla/5.0 (X11; Linux i686; rv:12.0a1) Gecko/20120105 Firefox/12.0a1 ID:20120105035122
Fails:
http://hg.mozilla.org/integration/mozilla-inbound/rev/c0b62edd2917
Mozilla/5.0 (X11; Linux i686; rv:12.0a1) Gecko/20120105 Firefox/12.0a1 ID:20120105041225
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=511078d51f71&tochange=c0b62edd2917

Suspected: bug 703100
Blocks: 703100
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression

Updated

6 years ago
Component: Untriaged → Layout: Text
Product: Firefox → Core
QA Contact: untriaged → layout.fonts-and-text

Comment 2

6 years ago
Created attachment 586719 [details]
Screenshot, comparison between Nightly12.0a1 and Aurora11.0a2
Assignee: nobody → jfkthame

Comment 3

6 years ago
Created attachment 586761 [details]
sample case

Comment 4

6 years ago
Line breaking inside PRE (including plain text) or TEXTAREA looks
taking line height in double.  Tried selection or F7.

I'm seeing this on Debian 6.0.3 but not on Ubuntu 11.10, Fedora 16, 
LinuxMint 12 nor VineLinux 6.

  Debian 6.0.3  GNOME 2.30.2
  Ubuntu 11.10  GNOME 3.2.1
  Fedora 16  GNOME 3.2.1
  LinuxMint 12  GNOME 3.2.1
  VineLinux 6  GNOME 2.32.1

Updated

6 years ago
Attachment #586761 - Attachment mime type: text/plain → text/html

Comment 5

6 years ago
FYI, In local build, First bad changeset;
561d06710107	Jonathan Kew — bug 703100 - pt 2.4.1 - make gfxPangoFontGroup font-matching behavior more similar to generic gfxFontGroup version. r=roc
tracking-firefox12: --- → ?
(Assignee)

Comment 6

6 years ago
What font(s) are being used to render the text when you see this problem? Please use "Show Fonts in Selection" from the fontinfo add-on[1] to verify the fonts being used both for the visible text and for the spaces.

[1] https://addons.mozilla.org/en-US/firefox/addon/fontinfo/
Created attachment 587072 [details]
Screenshot of the bug with fontinfo box

(In reply to Jonathan Kew (:jfkthame) from comment #6)
> What font(s) are being used to render the text when you see this problem?
> Please use "Show Fonts in Selection" from the fontinfo add-on[1] to verify
> the fonts being used both for the visible text and for the spaces.
> 
> [1] https://addons.mozilla.org/en-US/firefox/addon/fontinfo/
2 fonts: DejaVu Sans Mono and wasy10
I've removed ttf-lyx package (http://packages.ubuntu.com/en/maverick/ttf-lyx), that contains wasy10, and restarted browser. I'm no longer see this bug.

Comment 9

6 years ago
(In reply to Jonathan Kew (:jfkthame) from comment #6)
> What font(s) are being used to render the text when you see this problem?
> Please use "Show Fonts in Selection" from the fontinfo add-on[1] to verify
> the fonts being used both for the visible text and for the spaces.
> 
> [1] https://addons.mozilla.org/en-US/firefox/addon/fontinfo/

 for the visible text:
Bitstream Vera Sans Mono (default on newly installed Debian 6.0.3)
However ,This happens on any font (Century Schoolbook L Roman, Sazanami Mincho Regular, IPAGothic, ...).

for the spaces:  cannot select.

Comment 10

6 years ago
I see the same thing as Alexander (on Debian testing), except that the first font is Droid Sans Mono; the ttf-lyx package is http://packages.debian.org/wheezy/ttf-lyx
(Assignee)

Comment 11

6 years ago
(In reply to Alice0775 White from comment #9)

>  for the visible text:
> Bitstream Vera Sans Mono (default on newly installed Debian 6.0.3)
> However ,This happens on any font (Century Schoolbook L Roman, Sazanami
> Mincho Regular, IPAGothic, ...).
> 
> for the spaces:  cannot select.

If you select a range of several words (so extending across the intervening spaces), does Show Fonts in Selection report more than any extra font (which would presumably be the font used for the spaces)?
(Reporter)

Comment 12

6 years ago
As suggested, I removed the ttf-lyx package from my system and text lines no longer appear double-spaced.

I also installed that fontinfo add-on and even though I'm no longer seeing the problem I do see two fonts reported when I ask it about a selection that includes a newline.  Example:

  DejaVu Sans Mono
  Terminus Regular

...while when I ask it about a selection that includes only letters and spaces I see only one font reported:

  DejaVu Sans Mono

Since I'm just a civilian I'm not sure if that's expected behavior.
That does seem undesirable.
Duplicate of this bug: 716795
(In reply to M ODonnell from comment #12)
> As suggested, I removed the ttf-lyx package from my system and text lines no
> longer appear double-spaced.

Same here.  (More specifically -- after uninstalling the package, I had to reload any tabs that were affected by this bug -- after the reload, they were unaffected.)

This is likely to affect people who've installed the word processor "Abiword" - in Ubuntu 11.04, the "abiword" package recommends "abiword-plugin-mathview" which depends on ttf-lyx
Version: 12 Branch → Trunk
(Assignee)

Comment 16

6 years ago
The problem is that many fonts don't include the newline character (as it's not supposed to be drawn as a character at all), but in the case of preformatted text, newline may be present in the text run when we perform font matching. (The same would apply to the tab character, too.) This means that font fallback may kick in and apply a different font to the newline (or tab) than the one being used for the "real" text, and if this font - like wasy10 - has substantially different metrics, it will disrupt line spacing.

I'm testing a patch that should fix this by making the font-matching process assign non-printing control characters to the same font as their surrounding text, even if the font doesn't explicitly "support" them.
(Assignee)

Comment 17

6 years ago
Created attachment 587275 [details] [diff] [review]
patch, don't switch fonts for non-printing control chars

This restores the significant part of the older gfxPangoFontGroup matching behavior prior to bug 703100: control characters will be treated as coming from the same font as the preceding text, regardless of whether they're actually present in it.

The same change is made in gfxFontGroup::FindFontForChar, because even though this was only reported for Linux, the problem could in principle arise on other platforms as well, depending on the particular repertoire of fonts installed locally.

I think we can create a reftest for this, though it may require building custom fonts to ensure we have a setup that exhibits the problem - will look into this further.
Attachment #587275 - Flags: review?(roc)
(Assignee)

Updated

6 years ago
Duplicate of this bug: 716858

Updated

6 years ago
Summary: Plain text in WWW pages now appears to be double-spaced? → Plain text in WWW pages now appears to be double-spaced? (line height is double, too tall, newlines)
Summary: Plain text in WWW pages now appears to be double-spaced? (line height is double, too tall, newlines) → Plain text in WWW pages now appears to be double-spaced? (line height is double, too tall, newlines, blockquote, pre)
(Assignee)

Updated

6 years ago
Duplicate of this bug: 716910
Attachment #587275 - Flags: review?(roc) → review+
(Assignee)

Comment 20

6 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/9c2ca2a79d79
Target Milestone: --- → mozilla12
https://hg.mozilla.org/mozilla-central/rev/9c2ca2a79d79
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
(Assignee)

Updated

6 years ago
Duplicate of this bug: 717852
I'm seeing this again, although intermittently now, on the 2012-01-12 build.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Duplicate of this bug: 717852
(Assignee)

Comment 25

6 years ago
Created attachment 588632 [details] [diff] [review]
patch 2, initialize font matching with the font-group's primary font

The remaining issue arises when the text run passed to ComputeRanges *starts* with a non-printing control character such as tab or newline which isn't present in the "real" font we're going to use, and fallback picks something like wasy10 with weird metrics.

To fix this, we can simply initialize the "previous font" to the font-group's primary face, instead of null, so that initial control characters will be assigned to this font instead of relying on (somewhat unpredictable) fallback behavior.

Tryserver build with this patch is at https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jkew@mozilla.com-a681b91239a9/ if people would like to check that it resolves the issue (which is dependent on your particular collection of installed fonts).
Attachment #588632 - Flags: review?(roc)
(Assignee)

Updated

6 years ago
Attachment #588632 - Attachment is patch: true
(In reply to Jonathan Kew (:jfkthame) from comment #25)
> Tryserver build with this patch is at
> https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jkew@mozilla.com-
> a681b91239a9/ if people would like to check that it resolves the issue
> (which is dependent on your particular collection of installed fonts).

This build fixes the problem on my Linux system.
Attachment #588632 - Flags: review?(roc) → review+
(Assignee)

Comment 27

6 years ago
Pushed patch 2 to inbound:
https://hg.mozilla.org/integration/mozilla-inbound/rev/1b67951de0a2
(Assignee)

Comment 28

6 years ago
https://hg.mozilla.org/mozilla-central/rev/1b67951de0a2
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED
This appears to be a regression in FF12. Are we comfortable with uplifting the patch on m-c to Aurora 12?
tracking-firefox12: ? → +
Both patches landed while mozilla-central was still Firefox 12, so they are already in Aurora for Firefox 12:

https://hg.mozilla.org/releases/mozilla-aurora/rev/9c2ca2a79d79
https://hg.mozilla.org/releases/mozilla-aurora/rev/1b67951de0a2
status-firefox12: --- → fixed
Whiteboard: [qa+]
Mozilla/5.0 (X11; Linux i686; rv:12.0a1) Gecko/20120109 Firefox/12.0a1
Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20100101 Firefox/12.0

Verified using sample test case on Ubuntu 11.10 with ttf-lyx fonts installed. 

Could previously reproduce the issue (with Gecko/20120109). No longer seeing this with f12 beta 3.
Status: RESOLVED → VERIFIED
status-firefox12: fixed → verified
Whiteboard: [qa+] → [qa!]
You need to log in before you can comment on or make changes to this bug.