750 bytes, text/html
8.89 KB, patch
|Details | Diff | Splinter Review|
10.08 KB, patch
|Details | Diff | Splinter Review|
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.76 Safari/537.36 Steps to reproduce: When I call getBBox() of a SVG element where an empty text element is contained, the returned rectangle seems to be wrong. Actual results: As a result I got always a rectangle with the x/y values of the origin (0,0). Expected results: I assume that an empty text element is not used for the calculation of the bounding box. In my attached examples, there a two groups, one without an empty text element and one with one. For me, both bounding boxes should be the same (100/100 x/y and 100/100 width/height), but they aren't.
Attachment #809025 - Attachment mime type: text/plain → text/html
Status: UNCONFIRMED → NEW
Component: Untriaged → SVG
Ever confirmed: true
Product: Firefox → Core
Summary: SVG: Wrong BBox if an empty text element is contained → SVG: Wrong BBox if an empty text element is contained with svg.text.css-frames.enabled
Broken since implementation of bug 655877 and svg.text.css-frames.enabled set to true by default (bug 839955).
Assignee: nobody → longsonr
Attachment #809198 - Flags: review?(cam)
BTW thanks for reporting this Willi, it's always good to find these things out during beta/aurora.
Comment on attachment 809198 [details] [diff] [review] patch Review of attachment 809198 [details] [diff] [review]: ----------------------------------------------------------------- Looks good. Could you add another test that exercises a case like: <g> <text/> <rect .../> </g> g.getBBox()
Attachment #809198 - Flags: review?(cam) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/91a3ab6c0d0a The letter t is different but it's undetectable to the human eye.
And it's on all Windows 7 *sigh* https://hg.mozilla.org/integration/mozilla-inbound/rev/6a99a44e4b18
https://hg.mozilla.org/mozilla-central/rev/e97818c39f6f https://hg.mozilla.org/mozilla-central/rev/91a3ab6c0d0a https://hg.mozilla.org/mozilla-central/rev/6a99a44e4b18
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
[Approval Request Comment] Bug caused by (feature/regressing bug #): bug 839955 User impact if declined: bounding boxes of SVG text may be calculated incorrectly. The area covered may also be calculated incorrectly leading to a greater area than necessary being repainted. Testing completed (on m-c, etc.): landed on m-c with tests Risk to taking this patch (and alternatives if risky): could back out bug 839955 and not take the rewritten SVG text support but we'd lose all the new features like underlining and various bug fixes that CSS text frames brings. String or IDL/UUID changes made by this patch: none.
Comment on attachment 811672 [details] [diff] [review] rollup patch for aurora/beta In support of keeping the new functionality enabled in Beta 25.
Fx 25 beta 9: 20131017174213 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:25.0) Gecko/20100101 Firefox/25.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:25.0) Gecko/20100101 Firefox/25.0 latest Aurora: 20131017004002 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:26.0) Gecko/20100101 Firefox/26.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:26.0) Gecko/20100101 Firefox/26.0 Verified the issue on Firefox 25 beta 9 and latest Aurora using the attached testcase on both 32-bit and 64-bit mode. Each time the results are: BBox 1 (w/o text): 100, 100, 100, 100 BBox 2 (with text): 100, 100, 100, 100
verified with Nightly build 20131024030204
You need to log in before you can comment on or make changes to this bug.