1.73 KB, text/xml
17.19 KB, image/png
12.64 KB, image/png
testcase to come
Created attachment 242537 [details] 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.
Summary: <html:input type="text"> inside <svg:foreignObject> is horribly broken → <html:input type="text"> inside scaled <svg:foreignObject> is horribly broken
Created attachment 242539 [details] screenshot - vertical scrolling where the 15px high area gets painted separately to the scaled area
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?
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.
(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.
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.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.