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




5 years ago
5 years ago


(Reporter: cloos, Assigned: jtd)



32 Branch

Firefox Tracking Flags

(firefox32 wontfix, firefox33 unaffected, firefox34 unaffected)




5 years ago
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., for any rfc number, is a good test case.

text/plain documetents are also affected.

Comment 1

5 years ago
Hmmm.  It looks like seamonkey inherited this regression.

FF32 also has regressed.

I’m not sure exactly which component should get it.
You could do a regression search with our automated tool:
Component: General → General
Keywords: regression
Product: SeaMonkey → Core
Version: SeaMonkey 2.29 Branch → 32 Branch
Component: General → Layout: Text

Comment 3

5 years ago
The bug did not exist in seamonkey 2.26.1.

I’m testing older ff now.

Comment 4

5 years ago
The bug does not occur in ff 31.1.0.

It is new in the 32 branch.

Comment 5

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

Comment 6

5 years ago
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.
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 (we need the Pushlog output line)
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

5 years ago
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.)
> if there is a suitable repo 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 has instructions.

Or you could just use the mozilla-central builds from (the .txt file in the same directory as the build has the revision id the build is from).

Comment 11

5 years ago
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 is the repo to bisect?

My clone is a bit old, pulling now.

Comment 12

5 years ago

./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.
Duplicate of this bug: 1065986
[Tracking Requested - why for this release]: Broken basic text functionality for a number of users.
Ever confirmed: true

Comment 15

5 years ago
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 match the 31.1 and 32 tarballs?
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

the checkins for bug 280443 seem to have caused this.
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1022481
Ah, it being fixed on trunk is why I couldn't reproduce the problem!, 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 repository and can (usually does) include some backported changes on top of the branchpoint changeset.

Comment 19

5 years ago
A missing break, eh?

Goo to see that it is fixed.


5 years ago
Duplicate of this bug: 1066882
Duplicate of this bug: 1070705


5 years ago
Assignee: nobody → jdaggett
Blocks: 280443
Duplicate of this bug: 1082177
You need to log in before you can comment on or make changes to this bug.