Note: There are a few cases of duplicates in user autocompletion which are being worked on.

[Camino]Text is not remeasured when font is changed and document is reloaded

NEW
Assigned to

Status

()

Core
Layout: Text
--
minor
15 years ago
8 years ago

People

(Reporter: Mark Mentovai, Assigned: dbaron)

Tracking

Trunk
mozilla1.6alpha
PowerPC
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [patch], URL)

Attachments

(5 attachments)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20030128 Chimera/0.6+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20030128 Chimera/0.6+

If a font is changed in the Fonts tab of the Appearance preference pane,
and the user reloads the document to apply the changes, the old
measurements are used and the resultant rendered page may look funny if
the metrics of the old and new typefaces differ.

Reproducible: Always

Steps to Reproduce:
Start with the default Western font set to the proportional font, as
Times 14.
Visit http://bugzilla.mozilla.org/show_bug.cgi?id=184092#c5 .
Do Navigator:Preferences:Appearance:Fonts.
Switch Proportional (Serif) face to Lucida Grande 14 and close Preferences.
Command-R (reload)
Actual Results:  
The proportional font was changed to Lucida Grande 14, but the page was
redrawn using the measurements from Times 14.  Because Times is, in
general, narrower than Lucida Grande at the same point size, various
bits of text will overrun each other.

Reload again, and the text will be drawn properly.

When switching from Lucida Grande back to Times, gaps will be visible
instead of overruns.

Expected Results:  
The text should have been measured and drawn properly after the first
reload.

Actually, the page should have been rendered again after the font was
changed.  (And it should have been done properly.)

Note that if multiple windows are open, and a change is made to the font
selection, the change is applied to the background windows but not the
foreground window.  And the measurement bug is still present.  (This is probably
a separate bug.)

0.6.0+-2003012807/10.2.3

Comment 1

15 years ago
Duplicate of bug 185957 ?
(Reporter)

Comment 2

15 years ago
I don't think so.  Bug 185957 is about the page not being redrawn with the new
fonts, which I mention here, but that's not what this bug is about.

This bug is about text not being remeasured.

Mark

Updated

15 years ago
Severity: normal → minor

Comment 3

15 years ago
Mark, please attach a couple of comparitive screen captures demonstrating the
problem. (They don't have to be huge, just some part of the page that looks wrong.)

Also, does this also happen using Mozilla? Please test it.
(Reporter)

Comment 4

15 years ago
Created attachment 115214 [details]
Initial view before changing font

These images were prepared using Chimera 0.6.0+-2003020507.

The bug is also present in Mozilla 1.3b-20030212.  Reassign it over there?
(Reporter)

Comment 5

15 years ago
Created attachment 115215 [details]
Changed typeface to Lucida Grande and reloaded.
(Reporter)

Comment 6

15 years ago
Created attachment 115216 [details]
Reloaded again with Lucida Grande
(Reporter)

Comment 7

15 years ago
Created attachment 115217 [details]
Changed typeface from Lucida Grande back to Times

Comment 8

15 years ago
Confirmed using Chimera/2003021707.
Status: UNCONFIRMED → NEW
Ever confirmed: true
mozilla bug
Assignee: saari → font
Component: General → Layout: Fonts and Text
Product: Camino → Browser
QA Contact: winnie → ian
Version: unspecified → Trunk
(Assignee)

Comment 10

14 years ago
Probably something (table code?) is botching the reflow reason.
Whiteboard: [reflow-reason]
(Assignee)

Comment 11

14 years ago
Actually, based on the comment that the problem is only happening in the
foreground window, I suspect that's wrong.  Perhaps something funny is going on
with nsPresContext::ClearStyleDataAndReflow .
Whiteboard: [reflow-reason]
(Assignee)

Comment 12

14 years ago
I'm unable to reproduce this in Mozilla, but I can reproduce it in Camino.

Could you give steps to reproduce for Mozilla?
(Assignee)

Comment 13

14 years ago
Created attachment 129888 [details] [diff] [review]
patch

This fixes it.	I need to poke into the prefs code to figure out why this works
in other places.  This also makes Camino apply font pref changes immediately.
(Assignee)

Comment 14

14 years ago
Taking.
Assignee: font → dbaron
Whiteboard: [patch]
Target Milestone: --- → mozilla1.6alpha
(Assignee)

Updated

14 years ago
Summary: Text is not remeasured when font is changed and document is reloaded → [Camino]Text is not remeasured when font is changed and document is reloaded

Comment 15

13 years ago
David, Pink, is that patch something we should include in Camino 0.8?
I don't suppose there's any chance that this patch still applies, is there?  

The remeasuring problem's certainly still present in Camino 0.9a1 and DeerPark
1.1a1, and one still has to switch prefPanes or close the prefs window for font
changes in Camino take effect.

Comment 17

12 years ago
David: do we still want that patch?

Comment 18

12 years ago
(In reply to comment #13)
> Created an attachment (id=129888) [edit]
> patch
> 
> This fixes it.	I need to poke into the prefs code to figure out why this works
> in other places.  This also makes Camino apply font pref changes immediately.

My apologies if this seems too elementary a question, but how do I apply the patch?
mento, dbaron: can you confirm that the remeasuring issue has been fixed sometime between when I made comment 16 and now?  I've tried on bugzilla and a couple of other places (to rule out the bugzilla skin change being involved), and it seems fixed in Camino 1.0 (and a recent trunk).

Camino's font prefs not updating until you switch prefPanes or close the prefs, on the other hand, has gotten really annoying with some bugs I've been QAing recently ;) so that part is definitely still b0rken.

Comment 20

11 years ago
(In reply to comment #19)
> Camino's font prefs not updating until you switch prefPanes or close the prefs,
> on the other hand, has gotten really annoying with some bugs I've been QAing
> recently ;) so that part is definitely still b0rken.

Should we just go ahead and file a new bug on that? Does Apple give guidance anywhere about whether prefs should always commit edits in real time, or wait until the prefs window is closed, or what? I suspect this is not the only pref pane where we fail to commit edits until un-selecting/closing. (For instance, the General prefs pane doesn't currently do this either, though a patch I've written for fixing another bug brings this behaviour to it.)

cl
QA Contact: ian → layout.fonts-and-text
You need to log in before you can comment on or make changes to this bug.