Fuzzy text on sidebars

RESOLVED FIXED in mozilla2.0b4



8 years ago
2 years ago


(Reporter: Timo Tolonen, Assigned: roc)



Windows 7
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 beta4+)


(Whiteboard: [firebug-p1])


(5 attachments)



8 years ago
User-Agent:       Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; en-US; rv:2.0b2pre) Gecko/20100716 Minefield/4.0b2pre Firefox/3.6.6
Build Identifier: 

Since retained layers landed sidebar text has been fuzzy even without D2D/DW.

To reproduce simply open either bookmarks or history sidebar. Text rendering is fixed if you switch between history sidebar and bookmarks sidebar (or vice versa) without closing the sidebar

Reproducible: Always

Comment 1

8 years ago
Created attachment 458064 [details]
Screenshot of the issue


8 years ago
Blocks: 564991
blocking2.0: --- → ?

Comment 2

8 years ago
Created attachment 458080 [details]
Screenshot: fuzzy text in Globefish extension text boxes

I'm also seeing this regression, but not with the sidebars.  I see it with the Globefish Language Tool extension.  I on Windows XP.
Keywords: regression

Comment 3

8 years ago
Also caused right-hand pane of DOM Inspector to be blurry.
I'm seeing this too with DirectWrite text rendering.
Ever confirmed: true


8 years ago
Duplicate of this bug: 580263

Comment 6

8 years ago
This happens on DOM Inspector 2.0.6 extensions.

Reproducible: Always

1.Open DOMi
2.Resize window in horizontally very slowly.

Font rendering is ugly in right pane of the window.

Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; rv:2.0b3pre) Gecko/20100724 Minefield/4.0b3pre ID:20100724040639


8 years ago
Duplicate of this bug: 581672

Comment 8

8 years ago
Firebug is unusable until this is fixed.
Whiteboard: [firebug-p1]


8 years ago
Duplicate of this bug: 579854


8 years ago
Duplicate of this bug: 582487
Just saw this comment in this week's status?

Retained layers

    * The most obvious retained-layers regressions fixed for beta3
Keywords: regressionwindow-wanted
Version: unspecified → Trunk


8 years ago
blocking2.0: ? → beta4+
Created attachment 463058 [details] [diff] [review]

Well, this is really a workaround. The underlying bug is the nsIView::GetOffsetToWidget is returning a non-pixel-aligned result for the widget for the root frame of the subdocument in the sidebar (when applied to the root view for the entire chrome hierarchy). And the reason for *that* is that ViewToWidgetOffset() is returning 0,0 for that widget which is incorrect.

But rather than fix that, a better thing to do is to just not create widgets for chrome subdocuments of chrome documents. They're linked into the view hierarchy anyway, so the widgets are just pain+overhead.
Assignee: nobody → roc
Attachment #463058 - Flags: review?(tnikkel)
Attachment #463058 - Flags: review?(tnikkel) → review+
Keywords: regressionwindow-wanted → checkin-needed
Whiteboard: [firebug-p1] → [firebug-p1][needs landing]
Last Resolved: 8 years ago
Flags: in-testsuite?
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [firebug-p1][needs landing] → [firebug-p1]
And backed out in http://hg.mozilla.org/mozilla-central/rev/abca98af611e - it did fine on the tryserver, when it was being pushed on top of bug 584193, but then that got backed out before I landed this, so then print preview tests were timing out a la http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1281311429.1281313499.16771.gz
Depends on: 584193
Resolution: FIXED → ---
Created attachment 464558 [details] [diff] [review]
fix tests

We try to print preview an iframe in a chrome document. This bug makes that iframe lose it's widget. Make the iframe we try to print preview a content iframe so it gets a widget. When we remove child widgets we will also fix up print preview to deal with not having a widget.
Attachment #464558 - Flags: review?(roc)
Comment on attachment 464558 [details] [diff] [review]
fix tests

Thank you, sir!
Attachment #464558 - Flags: review?(roc) → review+
Keywords: checkin-needed
Whiteboard: [firebug-p1] → [firebug-p1][needs landing]

Comment 17

8 years ago
This appears to be fixed in latest nightly build for me, can anyone confirm?
(In reply to comment #8)
> Firebug is unusable until this is fixed.

It's now fixed on trunk - can you confirm that it meets your needs?
This patch hasn't landed yet, so if this is fixed on trunk, something else fixed it...
And we should still take this patch even if the fuzzy text problem is fixed.

Comment 21

8 years ago
Definitely NOT fixed.  Still see fuzzy text in right-hand side of DOM Inspector, with latest hourly build.

Comment 22

8 years ago
I do *not* see fuzzy text in Firebug 1.7a1 on 
Mozilla/5.0 (Windows NT 6.1; rv:2.0b4pre) Gecko/20100810 Minefield/4.0b4pre

Comment 23

8 years ago
Created attachment 464704 [details]
Screenshot: Fuzzy Dom Inspector (Aug 10, 2010 21:25 hourly build)

Rather than engage in pointless debate, here's a screenshot with proof that this bug remains (August 10, 2010 21:25 hourly build):

Mozilla/5.0 (Windows NT 5.1; rv:2.0b4pre) Gecko/20100810 Minefield/4.0b4pre  ID:20100810200338


This patch is definitely needed.

Comment 24

8 years ago
I am not debating your results, I am only reporting mine as requested by comment 18.

Comment 25

8 years ago
The point of my comment and John's comment was to point out that the fuzzy text has been fixed in Firebug but not fixed in other locations. This is just providing more information that could be useful.

There is no debate about a patch being needed as Robert stated. It is definitely needed.

Comment 26

8 years ago
At least the sidebar part was fixed/hidden by bug 575870 but since it was backed out, the issue will be visible again in the next nightly build.
Last Resolved: 8 years ago8 years ago
Resolution: --- → FIXED


8 years ago
Keywords: checkin-needed
Whiteboard: [firebug-p1][needs landing] → [firebug-p1]
Target Milestone: --- → mozilla2.0b4

Comment 28

8 years ago
Firebug 1.7a1 does *not* have fuzzy text on 
Mozilla/5.0 (Windows NT 6.1; rv:2.0b4pre) Gecko/20100816 Minefield/4.0b4pre


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