368987 - Identify on a SVG map crashs because of an EventListener problem

Status: RESOLVED WORKSFORME

(Core :: SVG, defect)

Description

[Armin Müller]

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

If you click on a geometry The geometry will be colored red and a window will be opened with attribute informations. 

The folowing error message can be found in the error console

Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMEventTarget.removeEventListener]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://global/content/bindings/browser.xml :: stopScroll :: line 683"  data: no]

After this all functionality is broken. 

Reproducible: Always

Steps to Reproduce:
1. click on a geometry. The geometry will be colored red and a window will be opened with attribute informations.
2. after closing the window all functionality is lost. You can not longer zoom in etc
3. this works well in FF 1.5 and FF 2
Actual Results:  
All interactions are broken

Expected Results:  
All interaction functionality should work. Same behavior as in FF 1.5 and FF 2

Comment 1

[Ria Klaassen (not reading all bugmail)]

This seems a regression between 2006-02-02:11 and 2006-02-02-13:
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2006-02-02+10%3A00&maxdate=2006-02-02+14%3A00
Maybe caused by bug 324600 or bug 322414?

Comment 2

[Ria Klaassen (not reading all bugmail)]

Bug 368991 has the same regression range.

Comment 3

[Boris Zbarsky [:bzbarsky]]

You're sure about the range, right?  None of those really look that likely...

I can confirm that the problem is there on a Mac, but I won't have access to one for a while, and on Linux I run into bug 369047 when I try to debug.  So I hate to say this... but it would really help to have a smaller testcase.  :(

Comment 4

[Armin Müller]

Attachment: A smaller example for testing

This is a smaller example with only one object.

Comment 5

[tor]

The behavior does change when I do builds before and after the bug 324600 checkin.

Comment 6

[Boris Zbarsky [:bzbarsky]]

That smaller example forced me to do a hard reboot of the machine... so I suspect you guys are kinda on your own here.  :(

I'll try code inspection, but that's a HUGE amount of code for a "smaller example"...

Comment 7

[Boris Zbarsky [:bzbarsky]]

So this seems to work for me on trunk now (on the original site).  Are you still seeing a problem?

Comment 8

[Ria Klaassen (not reading all bugmail)]

The crash was fixed in the beginning of August this year, but now I see weird imprints of the tooltips. The tooltip shadows are not caused by the fix of the crash in any case. 

Comment 9

[Armin Müller]

We have fixed the problem with the crash on our code.
The problem was the <a> tag.

We have used it in the following way:

<!ATTLIST svg
xmlns:mvns CDATA #FIXED "http://www.mapview.de">
<!ATTLIST a
xlink:href CDATA #IMPLIED>
]>
<a xlink:href=""><g id="th0" mvns:minscale="1" mvns:maxscale="1000000000000" mvns:scaleEle="" mvns:styleprop="fill" onclick="parent.identify(evt,'list','xml');" display="inline">
</g></a>

Comment 10

[Ria Klaassen (not reading all bugmail)]

Ah well, it crashes on a build on 1 August (20070801220 but not anymore on 2 August (2007080222) but maybe this was a different crash.

For the tooltip shadow bug I filed Bug 401212. 

Comment 11

[Ria Klaassen (not reading all bugmail)]

(In reply to comment #10)
> Ah well, it crashes on a build on 1 August (20070801220 but not anymore on 2
> August (2007080222) but maybe this was a different crash.
> 
I didn't read the report thoroughly enough by the lack of time, sorry. Was distracted by the word crash in the summary and by the tooltips. Reopening.

Comment 12

[Boris Zbarsky [:bzbarsky]]

> We have fixed the problem with the crash on our code.

Which crash?  Are you talking about bug 369047?  If you made a server-side change that eliminates that bug, could you please post the original (pre-change) code there?

Comment 13

[Armin Müller]

Boris 
You find it in the attachment from 02/02/07

Comment 14

[Boris Zbarsky [:bzbarsky]]

Ah, ok.  Great.  That doesn't seem to trigger bug 369047.

I also don't see the problem this bug describes on that testcase (once I reset the file:// security policy to be backwards compatible).

Comment 15

[tor]

Sounds like this is now a "works for me".