Identify on a SVG map crashs because of an EventListener problem

RESOLVED WORKSFORME

Status

()

Core
SVG
RESOLVED WORKSFORME
11 years ago
10 years ago

People

(Reporter: Armin Müller, Unassigned)

Tracking

({regression})

Trunk
x86
Windows XP
regression
Points:
---
Bug Flags:
blocking1.9 ?

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

104.33 KB, application/x-zip-compressed
Details
(Reporter)

Description

11 years ago
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
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?
Bug 368991 has the same regression range.
Assignee: nobody → general
Component: General → SVG
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → Trunk
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.  :(
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9?
Keywords: regression
(Reporter)

Comment 4

11 years ago
Created attachment 253739 [details]
A smaller example for testing

This is a smaller example with only one object.

Comment 5

11 years ago
The behavior does change when I do builds before and after the bug 324600 checkin.
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"...
So this seems to work for me on trunk now (on the original site).  Are you still seeing a problem?
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. 
(Reporter)

Comment 9

10 years ago
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>

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. 
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
(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.

Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
> 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?
(Reporter)

Comment 13

10 years ago
Boris 
You find it in the attachment from 02/02/07
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

10 years ago
Sounds like this is now a "works for me".
Status: REOPENED → RESOLVED
Last Resolved: 10 years ago10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.