Closed
Bug 49120
Opened 24 years ago
Closed 23 years ago
link properties not reflected until user interacts with the link
Categories
(Core :: DOM: Core & HTML, defect, P2)
Tracking
()
VERIFIED
FIXED
mozilla0.9
People
(Reporter: sean, Assigned: joki)
References
Details
(Keywords: dom0, Whiteboard: [nsbeta3-][PDTP2][rtm-])
Attachments
(4 files)
1.01 KB,
text/html
|
Details | |
26.91 KB,
patch
|
Details | Diff | Splinter Review | |
57.78 KB,
patch
|
Details | Diff | Splinter Review | |
11.94 KB,
patch
|
Details | Diff | Splinter Review |
Link properties like onmouseover are not accessible from javascript until the user has interacted with the link. They should be fully reflected by the time that a onload handler is called.
Reporter | ||
Comment 1•24 years ago
|
||
Reporter | ||
Comment 3•24 years ago
|
||
cc tim (this breaks the beatnik music object wizard extensions)
Reporter | ||
Comment 5•24 years ago
|
||
What does 'egk' in the whiteboard mean?
Comment 6•24 years ago
|
||
It means it's a bug that I'm quite concerned about having nsbeta3-ed and am marking for possible status review or exception fix status for RTM.
Reporter | ||
Comment 7•24 years ago
|
||
This breaks link mouseovers on the Beatnik website. The mouseovers are handled by a js script that we distribute to content developers - so problem is not limited to www.beatnik.com. Rather than adding mouseover code by hand to every link, it is done dynamically via a sourced in js script to add sound effects, etc to links and form elements. The documentation for the script is at: http://www.beatnik.com/software/documentation/music_object/index.html In the index frame, scroll down to the section labeled "Music Object Extensions" - the Wizards extension works with mouseover and mouseclick properties of links. A more direct url to the documentation (less the frames): http://www.beatnik.com/software/documentation/music_object/music-object- reference/extensions/wizards/index.html I previously wrote that the link properties should be fully reflected by the time that the document loads. I think this can be refined: link properties should be fully reflected when they are accessed via js (even if the user has not interacted with them).
Comment 8•24 years ago
|
||
Increasing priority to P2 as this is high profile backward compatibility (breaking JS 1.0 DOM0 and showing up on beatnik.com site). No workaround either. This would qualify for a check-in through 9/21 with mozilla reviewers approval. Can we find someone to fix this?
Priority: P3 → P2
Assignee | ||
Comment 9•24 years ago
|
||
Okay, I'll take this one. We know the problem and have a plan for a fix.
Assignee: jst → joki
Assignee | ||
Updated•24 years ago
|
Comment 10•24 years ago
|
||
*** Bug 46868 has been marked as a duplicate of this bug. ***
Comment 11•24 years ago
|
||
Marking nsbeta3+. Tom knows how to fix this.
Keywords: rtm
Whiteboard: [egk] → [nsbeta3+]
Comment 13•24 years ago
|
||
This didn't make the beta 3 train. Marking nsbeta3- and nominating for rtm. Requesting an exception fix approval from PDT by marking this rtm+
Keywords: rtm
Whiteboard: [nsbeta3+][PDTP2] → [nsbeta3-][PDTP2][rtm+]
Comment 14•24 years ago
|
||
PDT marking [rtm need info] until patch and code reviews are available.
Whiteboard: [nsbeta3-][PDTP2][rtm+] → [nsbeta3-][PDTP2][rtm need info]
Assignee | ||
Comment 15•24 years ago
|
||
Okay, I've got the fix ready and tested for this. Basically what I did is to add an CompileScriptEventListener call onto nsIEventListenerManager. I then called into this in the JS Resolve methods on nsDocument and nsGenericElement. I also added it into the Get{event handler name} methods on nsGlobalWindow. So if someone asks for a JS event listener, we force it to compile, if it exists. Otherwise we do nothing.
Assignee | ||
Comment 16•24 years ago
|
||
Comment 17•24 years ago
|
||
Tom, please check this into the trunk after doing pre-checkin testing. Unfortunately, it'll be difficult to justify checking this fix into the rtm branch. Marking rtm-.
Whiteboard: [nsbeta3-][PDTP2][rtm need info] → [nsbeta3-][PDTP2][rtm-]
Comment 19•24 years ago
|
||
I don't think ns601 means "please get in for Netscape 6.01", but maybe ekrock can say more about this misnamed keyword. I removed nsbeta3 and rtm, and added mozilla0.9. joki, is this on the trunk yet? I don't see reviewer-stamps in the bug; I have a few comments myself: + nsAutoString mPropName, mPrefix; + mPropName.Assign(NS_REINTERPRET_CAST(const PRUnichar*, JS_GetStringChars(JS_ValueToString(aContext, aID)))); + if (mPropName.Length() > 2) + mPrefix.Assign(mPropName.GetUnicode(), 2); + if (mPrefix.EqualsWithConversion("on")) { and similar code in nsGenericElement.cpp should not copy into two nsAutoStrings just to check for "on" (also, this particular case should not use the mPropName convention reserved for class members, but that variable's unnecessary anyway). Instead, use a zero-string-copy test: + JSString *str = JSVAL_TO_STRING(aID); + if (JS_GetStringLength(str) > 2) { + const jschar *chars = JS_GetStringChars(str))); + if (chars[0] == 'o' && chars[1] == 'n') { Does the new "replaceable" attribute in IDL help at all in shrinking the size of this patch? It can be used to define properties lazily from resolve. Cc'ing jst and vidur for advice. /be
Comment 20•24 years ago
|
||
*** Bug 35463 has been marked as a duplicate of this bug. ***
Comment 21•24 years ago
|
||
*** Bug 37584 has been marked as a duplicate of this bug. ***
Comment 22•24 years ago
|
||
Nom. nsbeta1. DOM correctness bug that's also actually affecting a real web site and plug-in (Beatnik).
Keywords: nsbeta1
Assignee | ||
Comment 23•24 years ago
|
||
I still have this fix from the last rtm cycle. I'll get it updated and checked in.
Target Milestone: --- → mozilla0.8
Assignee | ||
Comment 24•24 years ago
|
||
*** Bug 57367 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 25•23 years ago
|
||
I've been talking with jst as I integrated this patch and we're going to change the code this lives in in the next week or two. So instead of putting this in now and then rewriting it next week I'm going to move this out to moz0.9 and put in the fix with the new code.
Target Milestone: mozilla0.8 → mozilla0.9
Assignee | ||
Comment 26•23 years ago
|
||
Assignee | ||
Comment 27•23 years ago
|
||
Assignee | ||
Comment 28•23 years ago
|
||
sr = jst
Assignee | ||
Comment 29•23 years ago
|
||
r = peterv Fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•