1065016 - monospace fonts not used when allow documents touse other fonts is off

Status: RESOLVED DUPLICATE of bug 1022481

(Core :: Layout: Text and Fonts, defect)

Description

[cloos]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0 SeaMonkey/2.29
Build ID: 20140908155410

Steps to reproduce:

Disable allow documents touse other fonts.




Actual results:

Starting with 2.29 <pre> sections get the Proportional font and not the Monospace font.


Expected results:

Previously <pre> and similar sections got whatever was specified for Monospace.

There are old bugs similar to this, but this is a regression since 2.28.

http://tools.ietf.org/html/rfcXXXX, for any rfc number, is a good test case.

text/plain documetents are also affected.

Comment 1

[cloos]

Hmmm.  It looks like seamonkey inherited this regression.

FF32 also has regressed.

I’m not sure exactly which component should get it.

Comment 2

[Matthias Versen [:Matti]]

You could do a regression search with our automated tool: http://mozilla.github.io/mozregression/

Comment 3

[cloos]

The bug did not exist in seamonkey 2.26.1.

I’m testing older ff now.

Comment 4

[cloos]

The bug does not occur in ff 31.1.0.

It is new in the 32 branch.

Comment 5

[cloos]

Oh, and I see that it also affects view source.

Comment 6

[cloos]

Removing the windowwanted flag since I narrowed it to a difference between 31 and 32.

Interestingly, the text boxes here—but not on other sites—are in mono, so some subset still works.

Comment 7

[Matthias Versen [:Matti]]

A regression range of one Release (between 31 and 32) is useless because it contains thousands of changesets. We need a regression range down to one single changeset or at least one day. I can find the regression range if i can reproduce the bug report but i need more information for that or you can do it yourself with http://mozilla.github.io/mozregression/ (we need the Pushlog output line)

Comment 8

[Matthias Versen [:Matti]]

hut return to early:
Can you please explain which setting in Firefox do you changed to which value and post a screenshot how it looks on your system.

Comment 9

[cloos]

I described the problem perfectly; by setting allow sites to use their own fonts off, the font specified in the Monospace: box (or dropdown for ff32) is no longer used, even for view source.

A screenshot isn't needed.

As for mozrgression, mozfile doesn’t build so that is unusable.

I can do a git bisect if there is a suitable repo and a reasonble build script (generating a build which will run w/o having to install it system-wide).  (Autoconf would be so much easier.)

Comment 10

[Boris Zbarsky [:bzbarsky]]

> if there is a suitable repo

https://github.com/mozilla/gecko-dev but note that the revision hashes there don't match the mercurial ones, which will somewhat complicate matters.  Of course you could also do a mercurial bisect...

> and a reasonble build script

https://developer.mozilla.org/en-US/docs/Simple_Firefox_build has instructions.

Or you could just use the mozilla-central builds from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/ (the .txt file in the same directory as the build has the revision id the build is from).

Comment 11

[cloos]

Oh.  I didn’t notice that hg has native bisect now.  (Or was it bzr which needed an add-on for bisect?)

I take it http://hg.mozilla.org/mozilla-central is the repo to bisect?

My clone is a bit old, pulling now.

Comment 12

[cloos]

Annoying.

./mach build dies with:

  warnings.warn("couldn't determine platform's TOTAL_PHYMEM", RuntimeWarning)
...
AttributeError: 'module' object has no attribute 'get_sysinfo'

Probably because it didn’t compile mozilla-central/python/psutil/psutil/_psutil_linux.c before trying to use it.

Might the system install of psutil block it?

Indeed, unmerging dev-python/psutil lets mach work.

Comment 14

[Boris Zbarsky [:bzbarsky]]

[Tracking Requested - why for this release]: Broken basic text functionality for a number of users.

Comment 15

[cloos]

hg tip did not reproduce the bug.

I’d still like to find where it started and ended, just in case it is something which might return.

Which revisions in http://hg.mozilla.org/mozilla-central match the 31.1 and 32 tarballs?

Comment 16

[Matthias Versen [:Matti]]

bug 1065986 helped me to understand the issue better - sorry for my brain lag

This doesn't happen in Firefox33beta or trunk builds so it's already fixed !

Regression range on trunk is:
No more inbounds to bisect
Last good revision: 17f1c024a18d
First bad revision: 58f1f6dbe7ce
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=17f1c024a18d&tochange=58f1f6dbe7ce

the checkins for bug 280443 seem to have caused this.

Comment 18

[Boris Zbarsky [:bzbarsky]]

Ah, it being fixed on trunk is why I couldn't reproduce the problem!  
[e-mail], I'm sorry I didn't test this in 32.  :(

Also, I really appreciate your willingness to dig into this.  For future reference (though I hope you won't need to bisect Gecko ever again!), the FIREFOX_AURORA_32_BASE tag is where Firefox 32 branched from mozilla-central and FIREFOX_AURORA_31_BASE the equivalent for Firefox 31; similar for other releases.

The actual source corresponding to the releases is in the https://hg.mozilla.org/releases/mozilla-release/ repository and can (usually does) include some backported changes on top of the branchpoint changeset.

Comment 19

[cloos]

A missing break, eh?

Goo to see that it is fixed.

Comment 21

[Lawrence Mandel [:lmandel] (use needinfo)]

Correcting tracking flags based on comment 16.