Closed Bug 225854 Opened 21 years ago Closed 21 years ago

event.target.rel has no properties in method onLinkAdded in tabbrowser.xml

Categories

(SeaMonkey :: Tabbed Browser, defect)

Product:
SeaMonkey
Component:
Tabbed Browser
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: bugs4hj, Unassigned)

References

Details

Attachments

(1 file)

Patch
4.26 KB, patch
bugs4hj
: review+
alecf
: superreview+
Details | Diff | Splinter Review
I keep getting this error: Error: event.target.rel has no properties Source File: chrome://global/content/bindings/tabbrowser.xml Line: 607 Steps to reproduce: 1)install MultiZilla 2)open JS console 3)right-click on a link 4)select "View Source in New Tab" Current result : the above error Expected result: no error I am using mozilla build 2003111415 but I have seen this error in versions back to 20031019 Note: this used to work just perfectly for over two years now...
Here is the code that triggers the bug: <method name="onLinkAdded"> <parameter name="event"/> <body> <![CDATA[ var tabBrowser = this.parentNode.parentNode; if (!tabBrowser.mPrefs.getBoolPref("browser.chrome.site_icons")) return; => if (!event.target.rel.match((/(?:^|\s)icon(?:\s|$)/i))) return;
Btw, this small patch worked for me: - if (!event.target.rel.match((/(?:^|\s)icon(?:\s|$)/i))) + if (!event.target.rel || !event.target.rel.match((/(?:^|\s)icon(?:\s|$)/i)))
CC'ing Neil for advice. Neil, what do you think of that patch?
What's event.target there? What's event.target.rel?
Well, hopefully, event.target is the actual <link> element that was added; event.target.rel would therefore be the rel attribute, i.e. a string; event.target.rel should therefore always have the "match" method. Perhaps you have installed some complex XBL that is retargetting the event? (Note that the "match" method is not the most efficient way to test a regexp.)
"Well, hopefully, event.target is the actual <link> element that was added; event.target.rel would therefore be the rel attribute, i.e. a string;" Not exactly, since you're opening a chrome URI from the console, so they won't have a <link> element, right? I wonder why onLinkAdded was triggered in the first place.
The document inside the view-source <browser> contains a <link> element. See http://lxr.mozilla.org/seamonkey/source/htmlparser/src/nsViewSourceHTML.cpp#559 So could you please answer the questions I asked in comment 4?
"So could you please answer the questions I asked in comment 4?" Sure Boris, I was working on it: This is the error on the JS Console that I used for this bug report: Warning: reference to undefined property this.mPanelContainer Source File: chrome://global/content/bindings/tabbrowser.xml Line: 1438 Values I get in 'onLinkAdded' are: event.target.localName = bindings event.target.getAttribute("id") = tabBrowserBindings event.target.rel = undefined
> event.target.localName = bindings Right. So the target is no longer the <link> due to some XBL-related retargeting going on somewhere. That code should really be using .originalTarget anyway, no?
Right, target should be replaced by originalTarget and that makes it work, without the error!
Well, there are two questions here: 1) Why did the event retarget when the original element wasn't anonymous? 2) How on earth did the event retarget to the XBL document? 1) is probably a manifestation of bug 196755; unfortunately all the related bugs have been fobbed off with the "just use originalTarget" workaround. Sigh. 2) is just plain weird.
> 1) Why did the event retarget when the original element wasn't anonymous? Something to do with when DOM events are created? See nsGenericElement::HandleDOMEvent, especially the: // Find out if we're anonymous. nsIContent* bindingParent = nsnull; if (*aDOMEvent) { (*aDOMEvent)->GetTarget(getter_AddRefs(oldTarget)); nsCOMPtr<nsIContent> content(do_QueryInterface(oldTarget)); if (content) bindingParent = content->GetBindingParent(); } else { bindingParent = GetBindingParent(); } part. > 2) How on earth did the event retarget to the XBL document? Yeah, that's just bizarre. HJ, does this happen in non-multizilla builds?
Yes, with mozilla build 2003111415 on WinXP (MultiZilla disabled) after loading this chrome url: chrome://global/content/bindings/tabbrowser.xml 100% reproducable for me without that little 'target' -> 'originalTarget' fix
There's no <link> element for XML documents, right?
Oh dear, me bad. I found the cause of this bug. I simply forgot to insert 'view-source:' before the original url and that seems to triggered this bug. However, I feel that this issue could still be solved. What do you guys think?
Attached patch Patch — — Splinter Review
OK, so I've figured out what's going on. When you open an unstyled XML document, we transform it into a source-like view and bind two anonymous stylesheets to it. These stylesheets generate DOMLinkAdded events which get retargetted to the XML document's document element. Then when the tabbrowser tries to examine the links to find out if they are icons it looks at the wrong element. Oh, and I got a bit carried away while writing the patch - I fixed a couple of minor bugs along the way.
Attachment #135796 - Flags: review?(bugs4hj)
Comment on attachment 135796 [details] [diff] [review] Patch R+ from me because this looks like it should be.
Attachment #135796 - Flags: review?(bugs4hj) → review+
Attachment #135796 - Flags: superreview?(bz-vacation)
It'll take me a bit to get to this (possibly not till after the 15th).
Attachment #135796 - Flags: superreview?(bz-vacation) → superreview?(alecf)
Comment on attachment 135796 [details] [diff] [review] Patch sr=alecf
Attachment #135796 - Flags: superreview?(alecf) → superreview+
Fix checked in.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
*** Bug 282016 has been marked as a duplicate of this bug. ***
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: