Last Comment Bug 293581 - Uncaught exception when calling getBBox onload
: Uncaught exception when calling getBBox onload
Status: RESOLVED WORKSFORME
: testcase
Product: Core
Classification: Components
Component: SVG (show other bugs)
: Trunk
: x86 Windows XP
: -- major with 11 votes (vote)
: ---
Assigned To: General SVG Bugs
: Hixie (not reading bugmail)
Mentors:
: 295589 373252 (view as bug list)
Depends on:
Blocks: 327705
  Show dependency treegraph
 
Reported: 2005-05-10 02:37 PDT by Victor Joukov
Modified: 2008-01-06 06:47 PST (History)
13 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Test file (642 bytes, image/svg+xml)
2005-05-10 02:40 PDT, Victor Joukov
no flags Details
Empty <g> element still throws exception error. (668 bytes, image/svg+xml)
2007-09-05 14:07 PDT, Bruce Rindahl
no flags Details

Description Victor Joukov 2005-05-10 02:37:23 PDT
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050509 Firefox/1.0+

getBBox method does not work for text element, throwing an exception, and as a 
consequence, getComputedTextLength returns 0 every time for any text elements.
JavaScript Console output looks like:
Error: uncaught exception: [Exception... "Component returned failure code: 
0x80004005 (NS_ERROR_FAILURE) [nsIDOMSVGLocatable.getBBox]" 
nresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: 
http://somesite/test_text_getBBox.svg :: g_onload :: line 14" data: no

where somesite is the site name where you put attached file with test

Reproducible: Always

Steps to Reproduce:
1. Open attached file
2. Text "This is a text" appears
3. Open JavaScript console and see an exception


Actual Results:  
Alert boxes does not appear

Expected Results:  
Two alert boxes, first with results of getBBox, second with result of 
getComputedTextLength should appear. Second alert box should have non-zero 
value as a text length.
Comment 1 Victor Joukov 2005-05-10 02:40:05 PDT
Created attachment 183136 [details]
Test file

This is a main test file for this bug.
Comment 2 tor 2005-05-10 09:21:12 PDT
getBBox is implemented - it's just failing to run because the onload is fired
before the frames are constructed.  You can see this if you call your g_onload()
with a onclick handler on the <test> element.
Comment 3 Victor Joukov 2005-05-10 11:18:11 PDT
So, when call to getBBox (I am more interested in non-zero result of 
getComputedTextLength for the purpose of text layout) is valid? ASV3 for IE 
works even at onload time. On the other hand, Mozilla's getBBox does not work 
on freshly created text elements even after onload. I suspect it does not 
measure text before actually drawing it, which is unfortunate. What possible 
workaround could be - e.g. creating new transparent element, pushing drawing 
queue somehow (waiting), then measuring?
Comment 4 tor 2005-05-10 11:47:08 PDT
I'm not necessarily saying our behavior is correct, just what was causing it.
Comment 5 Victor Joukov 2005-05-10 12:44:20 PDT
Can you direct me to an appropriate section of SVG spec? I did not find 
anything about timing (or, more correctly, order?) of events and 
methods/attributes. Or is it in more general DOM specs?

I do not claim that Adobe's behaviour is correct either, it is just much more 
convenient from the DOM user's point of view. Otherwise it is hard to arrange 
text elements nicely, because you don't have means to measure text and adjust 
it in a cross-platfrom way (except using loadable fonts, which I am very 
reluctant to use for several reasons, not last of them is lack of hinting), so 
you are forced to rely on some run-time measurements.

So, do you believe that this issue is worth resolving?
Comment 6 tor 2005-05-10 13:14:04 PDT
Our behavior should be fixed, but I think the solution will involve a lot of effort.

http://www.w3.org/TR/SVG11/interact.html#EventsLoad
Comment 7 Robin Berjon 2005-05-10 19:11:26 PDT
(In reply to comment #3)
> What possible 
> workaround could be - e.g. creating new transparent element, pushing drawing 
> queue somehow (waiting), then measuring?

You may be able to get it to work by calling forceRedraw() before you ask for the length or bbox (http:/
/www.w3.org/TR/SVG/struct.html#InterfaceSVGSVGElement). I'm not sure it'll work in this case but it 
was the workaround when other implementations had the same bug.
Comment 8 Victor Joukov 2005-05-10 22:08:55 PDT
Doesn't work, unfortunately.
I inserted in my example two lines of code just before reference to getBBox:
  var svgs  = document.getElementsByTagName("svg")
  svgs[0].forceRedraw()
with no desirable effect.

Though, after once being shown the text node becomes fully functional, so if
you don't need to measure text while onload is processed, but only later, the
work around looks like following: place some text with proper style and 
nonsense coordinates (opacity=0 does not help - not implemented in Mozilla, 
visibility=hidden will break even ASV3 - no need to display, no way to 
measure ;-) under correct transform like this:

&lt;text id="measure" x="-10000" y="-10000"&gt; &lt;/text&gt;

Space between &lt;text&gt; and &lt;/text&gt; is important, otherwise there will
be no child node with data created.

Then if you need to measure a piece of text:

 measureNode = document.getElementById("measure")
 measureNode.firstChild.data = someText
 w = measureNode.getComputedTextLength()

This one works cross-platform.
Comment 9 Jonathan Watt [:jwatt] (Away Jun. 27 - Jul. 13) 2005-06-30 17:26:14 PDT
*** Bug 295589 has been marked as a duplicate of this bug. ***
Comment 10 Jonathan Watt [:jwatt] (Away Jun. 27 - Jul. 13) 2006-03-01 05:10:11 PST
Increasing the severity. This is causing problems for a lot of people and we don't have a workaround.
Comment 11 Jaroslav Zaruba 2006-07-17 09:12:00 PDT
Speaking of workarounds, there is one that works for me so far: to trigger the redrawing procedures by function that gets called by setTimeout(myRedrawFc, 0).

(I do apologize for such an OT post, but there might be more desperate people just as I was.)
Comment 12 Catalin Hritcu 2006-12-11 01:33:25 PST
The bug is still present in Firefox 3.0 Alpha 1: Grand Paradiso (Gecko 1.9a1). When is this bug going to be at least assigned?
Comment 13 Andreas Neumann 2007-02-05 13:41:21 PST
Hello,

I don't want to be annoying, but I wonder if someone is working on this problem? .getBBox() is a very important method and many people use it from onload scripts. Firefox is the only browser/UA failing when getBBox() is called "onload".

I would really appreciate if this problem could be fixed in the near future (at least before FF3 is released).

Thank you!
Comment 14 Duncan Loveday 2007-03-12 02:24:28 PDT
*** Bug 373252 has been marked as a duplicate of this bug. ***
Comment 15 David Zbarsky (:dzbarsky) 2007-07-29 13:56:20 PDT
In FF3 a7pre the testcase produces two alerts, and no errors.
Comment 16 Andreas Neumann 2007-08-02 02:05:55 PDT
I can confirm that this bug is now fixed in FF3 a7pre (already worked in a5pre).

This is really good news

Andreas
Comment 17 Bruce Rindahl 2007-09-05 14:07:30 PDT
Created attachment 279788 [details]
Empty <g> element still throws exception error.

The bug is still there when the element is a valid node but is empty.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007090504 Minefield/3.0a8pre
Comment 18 Robert Longson 2008-01-06 06:47:41 PST
Comment 17 is a different bug and has nothing to do with onload. Please raise a new bug for it i.e. GetBBox does not work with empty elements.

Note You need to log in before you can comment on or make changes to this bug.