356999 - <html:input type="text"> inside scaled <svg:foreignObject> is horribly broken

Status: RESOLVED WORKSFORME

(Core :: SVG, defect)

Description

[Jonathan Watt [:jwatt]]

testcase to come

Comment 1

[Jonathan Watt [:jwatt]]

Attachment: testcase

In this testcase you can set a scale on the foreignObject and choose to preserve the aspect ratio of that scale or not. I see many bad bugs.

* At a scale of 1 things are mostly normal except for the repainting issues covered by bug 350698

* Preserving aspect ratio and changing the scale the text sometimes draws at sizes from previous scales while the text selection is from another scale, and when you try a hard refresh of the page (even after making changes to the source!) the scale of text can still be broken. The only way to fix this seems to be to restart the browser.

* Hard refreshes can also cause the parent HTML content such as the buttons to get vertically but not horizontally scaled or something weird like that (screenshot coming up for that one)!

* When you change the aspect ratio the horizontal scale of the text changes as you try to select and then deselect it.

* After increasing the scale, it is sometimes possible to mousedown on the text and when you move the cursor up and down, the input will scroll vertically. When this happens you can also see that there is a 15px high region (the input is marked as being 15px high in CSS) paints separately to the rest of the enlarged input. It seems like some code is using the unscaled dimensions of the input while other code is using the scaled height.

* Other bugs I forget right now, but the more you play with this testcase the more you brokenness you find.

Comment 2

[Jonathan Watt [:jwatt]]

Attachment: screenshot - HTML weirdly affected by grandchild SVG

Comment 3

[Jonathan Watt [:jwatt]]

Attachment: screenshot - vertical scrolling where the 15px high area gets painted separately to the scaled area

Comment 4

[Jonathan Watt [:jwatt]]

The failure of the text to scale when the aspect ratio is changed (only the letter spacing is changed) got me wondering about the pxToTwips and twipsToPx variables we have scattered through the source. The assumption in this code seems to be that the aspect ratio remains constant. Is that correct? If so, are there any plans to fix this?

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

No, aspect ratio changes should be handled by cairo and be invisible to layout.

I do see slight up-and-down scrollability (probably something to do with rounding error in event coordinates) but other than that everything seems to work fine on Linux. I suspect a lot of the problems you're seeing are Win32 cairo bugs, probably text related.

Comment 6

[Jonathan Watt [:jwatt]]

(In reply to comment #5)
> No, aspect ratio changes should be handled by cairo and be invisible to
> layout.

Okay, great. Thanks.

Yes, most of the time the scrollability is very small, but sometimes it will scroll by an entire line height as shown by attachment 242539 [details]. It seems to be hard to reproduce. This happens when the cursor touches the top and bottom edges of where the input would be if it _wasn't_ scaled, not the top and bottom as painted.

Comment 7

[Jonathan Watt [:jwatt]]

Most of the issues mentioned in comment 1 have gone, presumably due to a combination of cairo and foreignObject fixes. I've opened bug 378879 for the scrolling issue and I'm closing this as WORKSFORME.