Closed
Bug 693076
Opened 13 years ago
Closed 11 years ago
elements.getElementsByTagName randomly returns 0 elements found
Categories
(Add-on SDK Graveyard :: General, defect, P1)
Add-on SDK Graveyard
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: nagle, Assigned: ochameau)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1 Build ID: 20110928134238 Steps to reproduce: In an add-on using a page-mod content script, code inserts some DIV elements, and later, looks them up with element.getElementsByTagName. Document is "text/html". Actual results: About 90% of the time this works, and about 10% of the time, getElementsByTagName fails to find the inserted DIV element. Checking code: var divsbad = elt.getElementsByTagName("div"); // get inner DIV elts var divs = getElementsByTagNameDefectWorkaround(elt, "div"); // use backup algorithm to work around bug if (divsbad.length != divs.length) // if results differ { GM_log("ERROR - getElementsByTagName returned " + divsbad.length + " vs correct value " + divs.length); dom_dump(elt, "DOM subtree for error"); // extensive debugging } Logging results look like this (for properly indented version, see "https://forums.mozilla.org/addons/viewtopic.php?f=27&t=4056&p=12475#p12475") info: ERROR - getElementsByTagName returned 0 vs correct value 7 info: DOM subtree for error info: <DIV> class = "strating" info: <DIV> class = "sticonlayer" info: <A> searchrater_inserted = "t" target = "_blank" href = "http://www.sitetruth.com/cgi-bin/ratingdetails.cgi?format=popup&url=www.afweather.af.mil" info: <IMG> border = "0" align = "right" src = "http://www.sitetruth.com/images/symbolwait.gif" alt = "Rating..." info: <DIV> class = "vspib" info: <DIV> class = "vspii" info: <DIV> class = "vspiic" info: <H3> class = "r" info: <A> class = "l" href = "http://www.afweather.af.mil/library/biographies/bio.asp?id=9023" searchrater_checked = "t" info: #text info: <EM> info: #text info: <DIV> class = "s" info: <DIV> class = "f kv" info: <CITE> info: <SPAN> class = "bc" info: #text info: <A> href = "/url?url=http://www.afweather.af.mil/library/index.asp&rct=j&sa=X&ei=vnuQTufpJ63PiAKO-LTMCA&ved=0CFkQ6QUoADAJ&q=colonel+carson&usg=AFQjCNEmVp4Q_TPDdeShWXf8CuvzeiwkBQ" searchrater_checked = "t" info: #text info: #text info: <A> href = "/url?url=http://www.afweather.af.mil/library/biographies/index.asp&rct=j&sa=X&ei=vnuQTufpJ63PiAKO-LTMCA&ved=0CFoQ6QUoATAJ&q=colonel+carson&usg=AFQjCNGn5wZrS7vynis38tzDY2OPlrdwOw" searchrater_checked = "t" info: #text info: <SPAN> class = "vshid" info: <A> onmousedown = "return clk(this,'http://webcache.googleusercontent.com/search?q=cache:mLkNpn4D7EsJ:www.afweather.af.mil/library/biographies/bio.asp%3Fid%3D9023+colonel+carson&cd=10&hl=en&ct=clnk&gl=us&client=firefox-a','','','','10','','0CFwQIDAJ')" href = "http://webcache.googleusercontent.com/search?q=cache:mLkNpn4D7EsJ:www.afweather.af.mil/library/biographies/bio.asp%3Fid%3D9023+colonel+carson&cd=10&hl=en&ct=clnk&gl=us&client=firefox-a" searchrater_checked = "t" info: #text info: #text info: <A> href = "/search?hl=en&client=firefox-a&hs=rCG&rls=org.mozilla:en-US:official&q=related:www.afweather.af.mil/library/biographies/bio.asp%3Fid%3D9023+colonel+carson&tbo=1&sa=X&ei=vnuQTufpJ63PiAKO-LTMCA&ved=0CF0QHzAJ" searchrater_checked = "t" info: #text info: <DIV> style = "display:none" id = "poS9" class = "esc kb" info: #text info: <A> class = "fl" href = "#" searchrater_checked = "t" info: #text info: <SPAN> class = "st" info: #text info: <EM> info: #text info: #text info: <EM> info: #text info: #text info: <B> info: #text info: <BR> Expected results: I've implemented workaround code which uses getElementsByTagNameDefectWorkaround instead of getElementsByTagName. Then checking code compares the results and dumps the DOM subtree. About 10% of the time, the checking code detects a difference and dumps the DOM subtree. The workaround result is correct and getElementsByTagName result is wrong. What I don't have is a simple test case. This is a port of a moderately large Greasemonkey script that's been working for months, and most of the files are shared between the Greasemonkey script and the Mozilla add-on. The same code works in Greasemonkey and fails in a Mozilla add-on. Of course, the timing is different in the add-on, because there are messaging delays as the content script talks to the add-on code. More details at https://forums.mozilla.org/addons/viewtopic.php?f=27&t=4056&p=12475#p12475 It's not a case issue. I've tried getElementsByTagName("div") and getElementsByTagName("DIV"). The results don't differ. So it's not that the add-on SDK is confused about the document type. More details at https://forums.mozilla.org/addons/viewtopic.php?f=27&t=4056&p=12475#p12475
Reporter | ||
Comment 1•13 years ago
|
||
Reproduce by: 1. Download entire add-on from "http://www.sitetruth.com/experimental/searchrater/searchrater.xpi". 2. Unpack and set up for use with "cfx run". 3. Change "verbose" to "true" in source. 4. Run plug-in on Google search results about 10 times. 5. Search for messages beginning "ERROR - getElementsByTagName".
Irakli, can you see what's going on here?
Assignee: nobody → rFobic
Whiteboard: [triage:followup]
Reporter | ||
Comment 3•13 years ago
|
||
Here's a version with debug output enabled: "http://www.sitetruth.com/experimental/searchrater/searchrater-debug.xpi". This produces huge amounts of output on the Javascript console, and if you do a few Google searches, you'll see the ERROR messages shown above.
Priority: -- → P1
Whiteboard: [triage:followup]
Comment 4•13 years ago
|
||
Alex, can you take a look at this one as it seems similar to Bug 702847 you fixed other day.
Assignee: rFobic → poirot.alex
Reporter | ||
Comment 5•13 years ago
|
||
Test with this if necessary. It's a complex add-on, not a simple test case, though.
Reporter | ||
Comment 6•12 years ago
|
||
Works fine in Google Chrome, incidentally.
Reporter | ||
Comment 7•12 years ago
|
||
Did someone just spam Bugzilla? "m" is "providor@hotmail.com" and this is their first posting to Bugzilla.
Comment 8•12 years ago
|
||
(In reply to John Nagle from comment #11) > Did someone just spam Bugzilla? > > "m" is "providor@hotmail.com" and this is their first posting to Bugzilla. Very likely. I have to admit, unsure what to do about that.
Comment 9•12 years ago
|
||
I have deleted the spam comments (But not comment 7 and 8 that mention it).
Assignee | ||
Comment 10•11 years ago
|
||
Most likely fixed by the removable os js proxies. Please reopen if I'm wrong.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•