Closed Bug 26402 Opened 26 years ago Closed 25 years ago

event handlers not compiled via element.setAttribute()

Categories

(Core :: DOM: Navigation, defect, P1)

Product:
Core
Component:
DOM: Navigation
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: kinmoz, Assigned: waterson)

References

Details

(Keywords: regression)

Attachments

(2 files)

proposed fix
5.47 KB, patch
Details | Diff | Splinter Review
better fix. move to nsXULElement::SetDocument()
3.67 KB, patch
Details | Diff | Splinter Review
In my 02/03/2000 WinNt debug build. Selecting a previously viewed page under the Browser's Go menu does nothing. It should take me to that page.
Cc don@netscape.com since I'm not sure if radha is on sabbatical or not.
yup. this is XP. note 'Back' and 'Forward' under 'Go' work fine, it's actually picking a site that is doing nothing. No console messages, nothing. This is also definitely a regression as it does not occur in hte 2000020108 WinNt builds. thanx kin.
OS: other → All
Hardware: PC → All
Keywords: regression
Summary: [REGRESSION] Browser's Go menu is broken → Browser's Go menu is broken
Well, this ought to be simple to fix ...
Assignee: radha → law
Priority: P3 → P1
Target Milestone: M14
Nominating as "beta1" blocker.
Keywords: beta1
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
*** Bug 26992 has been marked as a duplicate of this bug. ***
This might be a webshell/new-session-history thing. Could be nasty. I'll try to have a look ASAP to find out more.
Whiteboard: [PDT+] → [PDT+] Feb15
*** Bug 27230 has been marked as a duplicate of this bug. ***
The menu items seem to be created correctly. It seems their oncommand handlers are not getting fired. I've heard reports that a similar bug has already been reported; I've pinged Chris Waterson to try to track that one down. Will update as soon as I hear anything.
Dave Hyatt suggested a workaround. I've tweaked nsBrowserInstance.cpp so that it now sets the oncommand handler attribute on the menu items *after* the element has been added to the document. This bypasses a known problem relating to the timing of the compilation of such handlers. I am reassigning this to Chris Waterson (it may be a dup of a bug he already has). I've removed "beta1" from the keywords and would ask that the [PDT+] status now be removed. The Go menu items now work so the root cause does not have to be fixed right now.
Assignee: law → waterson
Keywords: beta1
Whiteboard: [PDT+] Feb15 → [PDT+]
Removing PDT+. Waterson wont be in until monday to look at this.
Whiteboard: [PDT+]
*** This bug has been marked as a duplicate of 27050 ***
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
My bad. This is -not- a dup.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Taking bug. See also bug 27050 and news://news.mozilla.org/38A0E3AD.EB7882DD%40mozilla.org, where I incorrectly posted a bunch of junk. I need to talk with vidur/joki to get a clear understanding of how the DOM working group expects properties and attributes to interact in the case of event handlers. Also, rename bug to be what it really means.
Status: REOPENED → ASSIGNED
Summary: Browser's Go menu is broken → event handlers not compiled via element.setAttribute()
this is not a history bug anymore right
QA Contact: claudius → janc
Attached patch proposed fix — — Splinter Review
*** Bug 30503 has been marked as a duplicate of this bug. ***
*** Bug 28238 has been marked as a duplicate of this bug. ***
Let's get this bad boy checked in. Have you made sure inline style works as well?
What's holding this bug up? waterson? waterson? :)
Target Milestone: M14 → M15
bonk. fix checked in. r=hyatt
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
inline styles don't work :(
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Blocks: 27934
Neither do the event handlers. Looking at the code, I couldn't find evidence that this bug had been fixed (maybe I'm blind). I didn't see a walk in SetDocument.
Look in AddSubtreeToDocument(). It's firing allright, because it helped keep the tree closed yesterday :-).
Is AddSubtreeToDocument not called from SetDocument? THat would explain why this didn't fix XBL, since anonymous content isn't ever placed in using DOM calls (there's only a back pointer to the parent from the child anonymous content).
No, it's not. It's only called when a "noisy" append/insert happens. Can you not do that? I'd be a bit nervous about adding the call on SetDocument() because it gets fired on a lot of different paths, but maybe that's the right place to do it... I'll tinker with it.
Ok, I remember why we can't do it on nsXULElement::SetDocument(). We want to force HTML elements to update themselves as well. I guess we could just punt on HTML elements for now and make this be vidur & jst's problem. XUL would work.
Let's fix it in XUL and then reassign the bug to jst, who can presumably make a fix in HTML at his leisure.
I've checked in the second attempt. Johnny, you can take this bug if you want, or open a new one for HTML elements.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Verified 2000-07-13-08-M17 : Linux 2000-07-13-09-M17 : WinNT & Win98 2000-07-13-08-M17 : Mac
Status: RESOLVED → VERIFIED
What are the odds that this is still broken for key events? oncommand's set manually for tree and outliner columnpickers don't fire upon pressing enter, but they do when clicked. (See http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/content/bindings/o utliner.xml#577) That seems unlikely, though, so this is probably a separate bug.
Component: History: Session → Document Navigation
QA Contact: jcarpenter0524 → docshell
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: