242924 - Invalid img longdesc tag breaks image properties dialog

Status: RESOLVED DUPLICATE of bug 175074

(SeaMonkey :: UI Design, defect)

Description

[Tommi]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040506 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040506 Firefox/0.8.0+

The example page contains sample images with a longdesc property. The last image
on the page has an invalid longdesc property, which causes the image properties
dialog to break (show's a long listing of properties, not just image properties)

Example page:
http://www.mozilla.org/quality/browser/standards/html/img_longdesc.html

Discussed in forums here:
http://forums.mozillazine.org/viewtopic.php?t=71642&highlight=

Reproducible: Always
Steps to Reproduce:
1. Goto http://www.mozilla.org/quality/browser/standards/html/img_longdesc.html
2. Move cursor over the last image on the page titled "Image long description
using an invalid absolute URL"
3. Right click and select "Properties"

Actual Results:  
Properties dialog breaks and shows properties for number of items.

Expected Results:  
Only show properties for the image.

Comment 1

[Tommi]

I've added pictures of the problem on the forum post here:

http://forums.mozillazine.org/viewtopic.php?p=515739#515739

Direct links:

Properties as they are supposed to be shown: 
http://www.saunalahti.fi/some2/ff_longdesc1.gif

Broken properties of the last image (which has invalid longdesc): 
http://www.saunalahti.fi/some2/ff_longdesc2.gif

Comment 2

[Tommi]

Forgot this from Javascript console:
(Firefox 20040506 Win32)

Error: uncaught exception: [Exception... "Component returned failure code:
0x804b000a [nsIURI.spec]"  nsresult: "0x804b000a (<unknown>)"  location: "JS
frame :: chrome://browser/content/metaData.js :: getAbsoluteURL :: line 446" 
data: no]

Comment 3

[Boris Zbarsky [:bzbarsky]]

Someone needs a try/catch around that newURI call...

Comment 4

[[e-mail]]

Actually the newURI is unnecessary because the longDesc property now returns an
absolute URI if one is available. In fact, that also applies to the cite
properties on the INS, DEL, Q and BLOCKQUOTE elements. That only leaves
xlink:href - do we have a property for that?

Comment 5

[Boris Zbarsky [:bzbarsky]]

No, for xlinks you have to do it by hand....

Comment 6

[Ben Basson]

Attachment: try / catch

This patch adds a try/catch as per Boris Zbarsky's comment. Does anything else
need doing, or is this acceptable as-is?

Comment 7

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 158526 [details] [diff] [review]
try / catch

I think this should be ok, yes.

Comment 8

[[e-mail]]

Comment on attachment 158526 [details] [diff] [review]
try / catch

This function won't return a value if the resolve fails. Also, you need to call
newURI each time, setting the spec is dodgy at best. It might be an idea to
take the document character set into account. Finally, the longDesc and cite
properties are now already absolute URLs.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Fixing bug 175074 would also fix this one.... (or vice versa)

Comment 10

[Ben Basson]

Wow, I totally forgot about this bug for absolutely months. Looks like it WFM
now, so I think this should be resolved as such. Neil, if you can tell me what
(if any) work needs to be covered by this bug and I'll see if I can do it.

Comment 11

[[e-mail]]

This was fixed by the check in for bug 175074.

*** This bug has been marked as a duplicate of 175074 ***