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.
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: http://mozilla.github.io/mozregression/
Component: General → General
Product: SeaMonkey → Core
Version: SeaMonkey 2.29 Branch → 32 Branch
The bug did not exist in seamonkey 2.26.1. I’m testing older ff now.
The bug does not occur in ff 31.1.0. It is new in the 32 branch.
Oh, and I see that it also affects view source.
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 http://mozilla.github.io/mozregression/ (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.
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 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).
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.
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.
[Tracking Requested - why for this release]: Broken basic text functionality for a number of users.
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?
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.
Status: NEW → RESOLVED
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! email@example.com, 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.
A missing break, eh? Goo to see that it is fixed.
Correcting tracking flags based on comment 16.
You need to log in before you can comment on or make changes to this bug.