360786 - [reflow branch] Text inside an svg foreignObject does not always position correctly

Status: RESOLVED WORKSFORME

(Core :: SVG, defect)

Description

[Filippo]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061112 Minefield/3.0a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061112 Minefield/3.0a1 REFLOW_20061031_BRANCH

The bug shows up for svg blocks with a viewbox, containing text as a foreignObject: if you toggle the svg attribute 'display' betweeen 'none' and 'block', on displays other than the first the reflows positions the text incorrectly.

Reproducible: Always

Steps to Reproduce:
1. Open the enclosed file buggy.xul
2. Press any key to display the text
3. Press a key again
4. Press a key again

Actual Results:  
On step 4 the text comes back again, but it displays a different way than after step 2.

Expected Results:  
At the end of (4) the text should look exactly like after (2).

- If you do not use the 'viewbox' attribute, or set a viewbox with a size matching the actual window size, the bug doesn't show up. To be precise, the closer the viewbox size is to the window size, the less visible is the bug.
- If you reload the document, the bug stops showing up.

I did some bug hunting, and I have seen that this comes out of a mismatch between the fontmetrics used by the reflow system and those used by the paint system. I have also seen that if you skip the drawing context font-cache at the right moment, the problem doesn't show up. This is how to do it:

- Run Minefield with a debugger
- Open buggy.xul in Minefield
- Press a key and display the text
- Press a key and hide the text
- Set a breakpoint in nsdevicecontext.cpp, line 601
- Set the focus to Minefield and press a key again
- When the program stops at the breakpoint, drag the execution pointer out of the 'if' block
- Run on the debugger
- The text will display correctly

Comment 1

[Filippo]

Attachment: Test case

Comment 2

[Filippo]

Attachment: Test case

Comment 3

[Bill Gianopoulos [:WG9s]]

Behavior is identical with a non-reflow trunk build.  This is NOT a reflow branch bug.

Comment 4

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20061207 Minefield/3.0a1 ID:2006120722 [cairo/reflow]

I see no difference between step 2 and 4

Comment 5

[Filippo]

I have updated to Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061210 Minefield/3.0a1 but the problem is still there.

The exact difference between steps 2 and 4 is that on step 4 I get a wider leading. How much wider depends on the relatioship between the viewbox settings and the actual window size. It might even get narrower if the viewbox is smaller than the viewport.

In some cases I have even had the system reflowing on the wrong words, with lines longer or shorter than expected.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

There have been a bunch of foreignObject fixes since this was last tested, and I don't see the bug.  Is it fixed for you in current trunk builds?

Comment 7

[Peter van der Woude [:Peter6]]

wfm

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070315 Minefield/3.0a3pre ID:2007031508 [cairo]

Comment 8

[Filippo]

Tried it with

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070320 Minefield/3.0a3pre

and it works now. Only problem: the text is now almost ureadable because spacing between characters is random, and often wider than spacing between words. But I guess that's another story.

Thanks to those who fixed it.

Comment 9

[Jonathan Watt [:jwatt]]

The character spacing issue is due to cairo. Closing this bug as WORKSFORME then.