374345 - Hyperlinks broken if "xlink:href" is changed after adding hyperlink to document

Status: RESOLVED WORKSFORME

(Core :: SVG, defect)

Description

[Duncan Loveday]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre)

In FF3, hyperlinks exhibit a variety of erratic behaviours if the value of attribute "xlink:href" is updated after the hyperlink (<A> element) is added to the SVG root element. Everything is fine as long as "xlink:href" is set before the hyperlink is added to the document.


Reproducible: Always

Steps to Reproduce:
1. Put the attached hyperlinkBug.html and hyperlinkBug.svg in a directory.
2. Open hyperlinkBug.html in Firefox.
3. Click anywhere on the black square a couple of times to observer expected behaviour.
4. Click anywhere outside of the black square to recreate the bug.
Actual Results:  
The black square, which is part of the hyperlink, works as expected - namely displaying an alert whenever it is clicked - until the user clicks anywhere else on the page. At this point the rectange disappears and does not reappear until the page is reloaded.

Expected Results:  
The black rectangle should not disappear and should carry on displaying alerts in response to clicks.

Test case works fine in FF2, so this is a regression.

In my real application, which has elaborate SVG layouts, I don't see the whole image turn white but I do observe hyperlinks that remain visible not working and a variety of unwanted behaviours including areas of the screen turning white and mouseover events not working until the user clicks on the target rather than just moving the mouse. I have so far been unable to recreate all these effects in a simple test case but all the effects I see are resolved when the xlink:href value is set before adding the hyperlink to the document. I'm hoping very much that the attached testcase will identify the underlying reason for all these effects.

Comment 1

[Duncan Loveday]

Attachment: test HTML source

Comment 2

[Duncan Loveday]

Attachment: test SVG source

Comment 3

[Jonathan Watt [:jwatt]]

This is another regression from bug 18333 (incremental XML).

Comment 4

[Duncan Loveday]

Disable incremental rendering of javascript content ? See comments against bug 374037.

Comment 5

[Duncan Loveday]

Upped the severity simply because this is a regression and will affect anyone using hyperlinks which could be a significant proportion of SVG users.

Comment 6

[Robert Longson [:longsonr]]

(In reply to comment #0)

I got an error in the Error Console every time with the test case. Changing the svg onload from top.loadSVG to parent.loadSVG fixed this although I don't see why that should be necessary. Once I did that the testcase worked every time for me.

BTW if you could produce testcases that work directly from bugzilla either as jwatt did in bug 374037 comment 5 or by constructing single svg file solutions where possible I would find that much more convenient.

Comment 7

[Duncan Loveday]

Attachment: Reattaching file that works live in the bug

Comment 8

[Duncan Loveday]

Robert, for me I get no errors in the javascript console and changing from top.loadSVG to parent.loadSVG makes no difference. Do you want to try the file I just attached ?

Comment 9

[Robert Longson [:longsonr]]

(In reply to comment #8)

I get the same effect as you now with the comment 7 version.

Comment 10

[Boris Zbarsky [:bzbarsky]]

The testcase worksforme.  Where is the problem?

Comment 11

[Duncan Loveday]

Are you testing using the same version (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre)?

I just tried with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/20070422 Minefield/3.0a4pre and it is still broken although the effect is slightly different - the rectangle disappears when clicked but re-appears when the alert is dismissed.

I also tried with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070512 Minefield/3.0a5pre and it is even more broken although - the rectangle disappears when clicked and doesn't re-appear when the alert is dismissed.

Can try the latest trunk tomorrow (currently on a dialup line, too long to install).

Comment 12

[Duncan Loveday]

Boris, I just noticed that after the image has disappeared it can be restored by re-sizing the window....might this be another bug that was fixed by the patch for bug 380516 ?

Comment 13

[Boris Zbarsky [:bzbarsky]]

> Are you testing using the same version

No, I'm testing current tip.  In this case, MOZ_CO_DATE="Sun Jun 3 09:34:01 CDT 2007".

And yes, this seems like something that bug 380516 could have fixed.

Comment 14

[Robert Longson [:longsonr]]

WFM now too with a current trunk build for what its worth.

Comment 15

[Duncan Loveday]

WFM with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070530 Minefield/3.0a5pre

Somthing between 12/5/and 30/5 must have fixed this.

Close as WFM ?