Closed Bug 579621 Opened 14 years ago Closed 14 years ago

Fuzzy text on sidebars

Categories

(Core :: Layout, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla2.0b4
Tracking Status
blocking2.0 --- beta4+

People

(Reporter: ttolonen, Assigned: roc)

References

Details

(Keywords: regression, Whiteboard: [firebug-p1])

Attachments

(5 files)

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
Attached image Screenshot of the issue
Blocks: 564991
blocking2.0: --- → ?
I'm also seeing this regression, but not with the sidebars.  I see it with the Globefish Language Tool extension.  I on Windows XP.
Also caused right-hand pane of DOM Inspector to be blurry.
I'm seeing this too with DirectWrite text rendering.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This happens on DOM Inspector 2.0.6 extensions.

Reproducible: Always

[STR]
1.Open DOMi
2.Resize window in horizontally very slowly.

[Actual]
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
Firebug is unusable until this is fixed.
Whiteboard: [firebug-p1]
Just saw this comment in this week's status?

Retained layers

    * The most obvious retained-layers regressions fixed for beta3
Version: unspecified → Trunk
blocking2.0: ? → beta4+
Attached patch fixSplinter 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+
Whiteboard: [firebug-p1] → [firebug-p1][needs landing]
http://hg.mozilla.org/mozilla-central/rev/ec28c1790e13
Status: NEW → RESOLVED
Closed: 14 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
Status: RESOLVED → REOPENED
Depends on: 584193
Resolution: FIXED → ---
Attached patch fix testsSplinter Review
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]
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.
Definitely NOT fixed.  Still see fuzzy text in right-hand side of DOM Inspector, with latest hourly build.
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
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

http://hg.mozilla.org/mozilla-central/rev/b1be7d4acee2

This patch is definitely needed.
I am not debating your results, I am only reporting mine as requested by comment 18.
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.
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.
Keywords: checkin-needed
Whiteboard: [firebug-p1][needs landing] → [firebug-p1]
Target Milestone: --- → mozilla2.0b4
Firebug 1.7a1 does *not* have fuzzy text on 
Mozilla/5.0 (Windows NT 6.1; rv:2.0b4pre) Gecko/20100816 Minefield/4.0b4pre
Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: