Overview Description: When you choose a menu item, and the mouse by chance hovers over a personal toolbar button, mouseover effects do not occur. Actual Results: Mouseover will only occur when you move the mouse, even though you're within the button the whole time. Expected Results: Menu dismissal should result in mouseover status being checked and turned on if necessary. Build Date & Platform Bug Found: Linux 1999112208

Must be a slow bugfinding day! assigning to saari as p5 for m20

taking popup/menu bugs. I hate my life.

bulk accepting xpmenu/popup bugs. sigh.

Mass move of all M20 bugs to M30.

Mass moving M20 bugs to M30

Mass-moving all M20-M30 XPToolkit bugs to Future

this bug has remained w/out comment from the author for about a year...does it still happen? i'm marking WFM since no one else has said anything...

This is still there as of M18. Be aware that personal toolbar buttons don't hover anymore. Choose Search/Find Again. such that you're hovering over the reload toolbar button. A dialog will about but the mouseover doesn't until you move the mouse slightly.

True of both Modern and Classic.

oh, but they eventually appear, right? Yeah, we don't do any hover resolution until mouse-move, so if a window comes to the front under the mouse, you won't see any :hover styles until the mouse moves. This is a gecko bug, not a toolkit bug.

oops --> clayton for triage

XML/DOM team's turn to triage Clayton's bugs.

*** Bug 62217 has been marked as a duplicate of this bug. ***

Has this bug been fixed, or partially fixed? I cannot duplicate the bug using the search menu. When I choose find again from the menu, my mouse ends up over the reload button and the reload button is properly highlighted without any mouse movement. (Windows build 2000122805 classic skin) I can check again on linux once I get to work.

Also the "previous date" test from Bug 62217 wfm. Again I will test on linux.

This bug appears for me in Linux (Build 2000122710). Maybe it should not be OS=ALL?

Bug 28934 is related.

hyatt: FYI

I can't reproduce this bug on 2001021812 Linux. The reload button's mouseover effect appears correctly without moving the mouse.

Coming here from bug 77051 ... Another issue: When I select one of the menus, for example "Tasks" and then hover over the toolbar buttons the following happens: 1. toolbar buttons are highlighted 2. the associated action doesn't trigger when I click One of the above behaviors is not correct (probably #2)

With regard to #2: I've read somewhere there is a difference between windows and Linux. On windows the actions are triggered on 'MouseDown' while on Linux it is 'MouseUp'. I'll try to confirm this. Otherwise this seems WFM

See also: bug 50511 scrolling/app switching under mouse should cause mousemove bug 78765 link left in :hover state after being hovered and scrolled off using mouse wheel [specific to mouse-wheel scrolling, doesn't happen with arrow keys]

I believe this is what I'm seeing intermittently when rolling over the main menus at the top of the window. It's as it the fact that I'm over the meny isn't 'caught' as a hover event. Soon as you move my one pixel the state is corrected.

This belongs in the Event Handling component. I believe Event Handling is quite recent, so it was not available when this bug was filed.

I can confirm this on 1.0 (2002053012) in WinXP. Dismissing a menu with the mouse over any toolbar button or the bookmarks will not cause the "hover" style to be in effect until you move the mouse slightly. This is similar to bug 150069, which deals with the :hover CSS pseudo-style in rendered HTML. The root cause may be the same.

*** Bug 168647 has been marked as a duplicate of this bug. ***

*** Bug 46388 has been marked as a duplicate of this bug. ***

I think what needs to happen here is that anytime we do a reflow or a scroll we should notify the event state manager that things have moved and it should (1) change the :hover-ed content, (2) set the cursor and (3; probably) fire mouseout/mouseover. There's currently a hack to do (some of?) this for the wheel scrolling case only. There might be some complications for the key scrolling case because of our use of GetFrameForPoint for key events, although hopefully we've fixed that. :-) This is actually one of the more basic bugs that really annoys me, so changing from P5 to P2.

http://bugzilla.mozilla.org/show_bug.cgi?id=179125#c3 joki is no longer here

I guess 'mozilla1.0' keyword should be removed/replaced now: v1.4 is released.

*** Bug 137412 has been marked as a duplicate of this bug. ***

After discussion with jst, I decided that these synthesized mouse movements should not lead to DOM mousemove events, but should lead to mouseover / mouseout events. This still needs a lot more testing.

(In reply to comment #33) > After discussion with jst, I decided that these synthesized mouse movements > should not lead to DOM mousemove events, but should lead to mouseover / > mouseout events. In several case, I praised the symmetry in the |dragenter|/|dragexit| events and cursed the absence of |mouseenter| in the DOM spec. Wouldn't it make sense to have such an event internally? mouseover can be resource consuming.

What's asymmetric about mouseover and mouseout? Are you sure you're not thinking of mousemove? (over == enter and out == exit may be abuse of the English language, but they're standardized, and symmetrical themselves)

I chose "over" and "out" as the prepositions long ago, in a fit of whimsy. Are we firing mouseovers continuously or something? /be

no

(In reply to comment #37) > What's asymmetric about mouseover and mouseout? arg, my bad! I got involved with mozilla with bug 139471 and bug 145350 that adds a the dragenter handler to our DND helper because dragover is firing continously. I naively assumed that mouseover had the same behaviour as dragover, but no, it fires only once, just like dragenter. Sorry for the my last comment, but it was highly beneficial for me, I have to fix one incorrect use that I made.

Comment on attachment 140124 [details] [diff] [review] patch >- if (baseView != view) { I thought this check was an optimization, but it's apparently required for :hover effects in popups to work. (Either that, or something else in my tree broke :hover inside popups.)

I can no longer reproduce the problem mentioned in my previous comment.

Ignore comment 42, actually. The problem is that we reflow everytime the user moves the mouse while over a menu. Probably the easy fix is not to synthesize a mouse move if there's a mouse grabber.

Well, there are two problems: * we reflow when the user moves the mouse over the bookmarks menu (probably because of the arrows) or a menu on the personal toolbar * when synthesizing the mouse event after than reflow, BuildEventTargetList seems to get a display list that thinks the view for the page content is above the view for the menu -- thus the top 2 items on the bookmarks menu work, but the rest don't.

The menu bug is bug 136301.

That's pretty weird. The views for menus are floating, so they should always be on top. In fact they are in normal operation, what could be different about this case?

ok, never mind. I was missing a coordinate system translation which messed things up for any views that weren't at the origin. The combination of that and the excessive menu reflow caused a little feedback loop (one cycle per mouse movement) where the menu switched from hovered to non-hovered on every mouse move.

So what happens when someone writes a test page where :hover causes an element to shrink, and someone moves the mouse just inside the element? Do we reflow, fire synthetic event, reflow, fire synthetic event forever? I presume so since that's kind of correct ... but can the user recover or does it lock up hard?

> fire synthetic event, reflow, fire synthetic event forever? I presume so since > that's kind of correct ... but can the user recover or does it lock up hard? is the synthetic event fired synchronously or async? Users are able to recover from async events merely by moving the mouse, which should still be possible given that we are still processing the event loop. If it's an async event/reflow loop we're pretty much gonna be toast, right?

Hmm. Perhaps the event should be fired asynchronously, then. The only case where the delay could matter is for :hover changing after a Reflow, and that's a relatively unimportant case.

this posts events to the queue

Comment on attachment 140231 [details] [diff] [review] patch Actually, never mind that. I realized some of the event queue changes I made here are bad for nested event loops.

Comment on attachment 140255 [details] [diff] [review] patch > reasonType Shouldn't this be ReasonType? > + * (aFromScroll is false) or scrolled (aFromScroll is true). Lose the reference to aFromScroll > handler_fn Make this HandlerFn? I thought we always made type names InterCaps. + // XXX set event.isShift, event.isControl, event.isAlt, event.isMeta ? I think you need to, right? Can you explain why you're not firing mousemove? Seems like mouse-tracking DHTML will get confused otherwise.

The DOM spec says that mousemove should be fired when the pointing device is moved, which it isn't in this case. Mouse-tracking DHTML mostly uses mouseover/mouseout, I'd hope. >+ // XXX set event.isShift, event.isControl, event.isAlt, event.isMeta ? >I think you need to, right? This would make the code a good bit more complicated, since the view manager will need to remember those states as well (assuming we get keyup / keydown events for them that can be reliably associated with the correct modifiers, which I'm not sure we do).

Also, I'm thinking maybe I should prevent the infinite loop from happening at all (since it suppresses paints, which can be confusing) by allowing an additional event to be posted only if the source is a scroll rather than a reflow.

> Shouldn't this be ReasonType? I was being consistent with the other member enum of an event (orientType).

avoid infinite loops, readd |aFromScroll|

> The DOM spec says that mousemove should be fired when the pointing device is > moved, which it isn't in this case. Well, the pointer is moving relative to the element... > Mouse-tracking DHTML mostly uses mouseover/mouseout, I'd hope. I meant xeyes-like hacks, or the pointer-following tooltips that some sites have. Can you think of any examples of pages that watch mousemove and wouldn't want it to fire because of scrolling or reflow? > This would make the code a good bit more complicated, Yeah, I don't know how to implement it either, I just think we should :-(. Maybe just change the comment to // XXX We should set event.isShift, event.isControl, event.isAlt, event.isMeta!

Comment on attachment 140425 [details] [diff] [review] patch >Index: view/src/nsViewManager.cpp >-nsInvalidateEvent::nsInvalidateEvent(nsViewManager* aViewManager) >+nsViewManagerEvent::nsViewManagerEvent(nsViewManager* aViewManager) > { > NS_ASSERTION(aViewManager, "null parameter"); >- mViewManager = aViewManager; // Assign weak reference > PL_InitEvent(this, aViewManager, > (PLHandleEventProc) ::HandlePLEvent, > (PLDestroyEventProc) ::DestroyPLEvent); As we discussed, you should be able to get rid of these casts now. >@@ -1959,72 +1955,71 @@ NS_IMETHODIMP nsViewManager::DispatchEve > view = mMouseGrabber; > capturedEvent = PR_TRUE; > } > else if (nsnull != mKeyGrabber && (NS_IS_KEY_EVENT(aEvent) || NS_IS_IME_EVENT(aEvent))) { > view = mKeyGrabber; > capturedEvent = PR_TRUE; > } > else { > view = baseView; > } > > if (nsnull != view) { >+ float t2p; >+ mContext->GetAppUnitsToDevUnits(t2p); >+ float p2t; >+ mContext->GetDevUnitsToAppUnits(p2t); >+ I realize you just moved this code around, but you could just say: float p2t = 1 / t2p; , couldn't you? sr=bryner with those changes.

This might help show what we're currently doing here. This prints out what DOM mouse{move,over,out} events are fired in a document. Turns out that IE, and Mozilla too, fires all those events when (de)activating a window (sometimes with different coordinates though), which I for sure didn't think we did.

This fixes the casts for the event handlers to PL_InitEvent and fires mousemove events as well. I didn't fix the dev2app/app2dev stuff because I've had enough rounding errors for today already.

Comment on attachment 140543 [details] [diff] [review] patch Oh, and after I land this I need to look into differences in what happens on activate events between Windows and GTK2...

Fix checked in to trunk, 2004-02-03 16:11 -0800.

This patch generates spurious mousemove events. It breaks a lot of extensions. For instance, in Firebird, load http://news.bbc.co.uk/ in one tab. Each time, the "ticker" for LATEST "writes", a squirt of mousemove events are generated even if the mouse doesn't move. Worst. If you listen mouse move events in another tab (at the level of content area) you get the mouse move events of the BBC tab when the ticker writes. You can imagine the result when you use mouse move events to draw gesture trails. Backing out for the moment seems reasonable.

(In reply to comment #62) > Created an attachment (id=140529) > Testcase that shows what DOM mouse{move,over,out} events are fired. > > This might help show what we're currently doing here. This prints out what DOM > mouse{move,over,out} events are fired in a document. Turns out that IE, and > Mozilla too, fires all those events when (de)activating a window (sometimes > with different coordinates though), which I for sure didn't think we did.

Not sending mousemove events is a very simple patch, and there's no need to back out. But why do the mousemove events break extensions?

This may have caused bug 233164

(In reply to comment #68) > But why do the mousemove events break extensions? Well, not all. Those that use mouse move as Optimoz mouse gestures, All-in-One gestures, Autoscroll, etc. Mousemove events should only be dispatched when the mouse pointer changes its coords on the screen (W3C DOM events says: "The mousemove event occurs when the pointing device is moved while it is over an element").

I still don't understand why these extensions can't handle a mousemove with unchanged coordinates.

(In reply to comment #66) > Worst. If you listen mouse move events in another tab (at the level of content > area) you get the mouse move events of the BBC tab when the ticker writes. You can > imagine the result when you use mouse move events to draw gesture trails. I can't reproduce this problem on Linux. Could you please file a separate bug with accurate steps to reproduce?

This patch breaks native Firebird Autoscroll as well (verified on Win XP with unofficial build from Mozillazine). (In reply to comment #71) > I still don't understand why these extensions can't handle a mousemove with > unchanged coordinates. Let's take the autoscroll feature as an example. You first middle-click to set the marker position. Then moving the mouse relative to the marker determines the scrolling direction and speed. If spurious mousemove events are generated, it breaks everything.

Comment on attachment 140756 [details] [diff] [review] restore code to prevent mousemoves from firing (checked in to trunk, 2004-02-06 15:10 -0800) bryner already reviewed this (as part of attachment 140425 [details] [diff] [review])

Comment on attachment 140756 [details] [diff] [review] restore code to prevent mousemoves from firing (checked in to trunk, 2004-02-06 15:10 -0800) I still think this is silly, but okay.

I investigated a little bit the problem. Firing mousemove events is not the real issue. It seems that the issue is that the mousemove events are fired with the coords of the element that is reflowed not the mouse coords. I'll make a testcase tomorrow to illustrate what I think the problem is.

This latest checkin seems wrong to me. IMNSHO the original fix was correct, we *should* fire mousemove events when a view is being scrolled. I would think that the DOM uses coordinates relaive to the document, not the viewport. Which means that when the document scrolls but the mouse stays stationary with respect to the viewport, the mouse *does* actually move with respect to the document. In other words: since the mouse is now positioned at a different position in the documents coordinate-space it must have moved and an event should be fired. However: Extensions such as optimoz and autoscroll should be using the chromes coordinate space. In that space the mouse hasn't moved so it could be argued that the event shouldn't be propagated through the chrome-DOM. And it should defenetly have the same coordinates through that DOM. In any event I don't see why the extnesions shouldn't be able to deal with these new events that are generated.

I liked it better when scrolling with the keyboard didn't fire mouseover. Now DHTML tooltips on e.g. http://www.bradchoate.com/ appear under the mouse cursor when I scroll using the keyboard.

Unofficial Firebird 20040207 WIn XP. Last checkin solved the mouse move problem. Still something wrong with http://news.bbc.co.uk/ . The mouse pointer cursor is changing from pointer to hand when the ticker plays. With native autoscroll (which uses a special cursor), mouse cursor toggles very quickly when ticker writes. Steps to reproduce: 1. Goto http://news.bbc.co.uk/ 2. bring the mouse pointer over the Latest ticker. 3. Move the mouse to the right of the page. watch the pointer that transforms to hand when the ticker plays. If the mouse is moved while the ticker writes, the mouse pointer flickers (changed at each new letter).

(In reply to comment #81) > I liked it better when scrolling with the keyboard didn't fire mouseover. Now > DHTML tooltips on e.g. http://www.bradchoate.com/ appear under the mouse cursor > when I scroll using the keyboard. This seems like a good thing to me. And it's much more consistent then to have the tooltip update just because i brush against the mouse or hit the desk with my elbow (i.e. when the mouse moves a pixel)

Me too. And if I don't want the tooltips, I can always move the cursor away.

This has most probably caused crash bug 233211. Look there for details.

I don't want to back out some of the cleanup that's essentially unrelated to this bug. I have a verbal a=chofmann on backing out.

Backed out.

This also seems to have caused the bug 234435 crash....

*** Bug 235108 has been marked as a duplicate of this bug. ***

There might be some similarity between fixing this and some of the issues related to keeping mouseover/mouseout/:hover state correct when the pointer is moving in and out of iframes. Worth considering before, or perhaps after, relanding.

*** Bug 243784 has been marked as a duplicate of this bug. ***

patch updated to trunk

This is the previous patch modified to fix bug 233164, bug 234435, and bug 238546. That basically leaves bug 233211 / bug 234188 and bug 233374, which all seem to be Windows-only.

This also fixed bug 233374. I'm unable to reproduce the drag & drop crashes on Win2K using the steps in bug 234188 comment 0, bug 233211 comment 0, or bug 233211 comment 7. Hopefully they've gone away, but perhaps they're Win9x-only, in which case I'll need help debugging. I think this is ready to land. If the crashes are still there, somebody can help debug.

Comment on attachment 150470 [details] [diff] [review] patch The main changes since the backout are the drag&drop stuff in nsEventStateManager.cpp, a null-check in nsPresShell.cpp, and the removal of the mRootView check on the NS_MOUSE_EXIT handling (with 6-line comment) in nsViewManager.cpp. I also fixed a change I only half-did the first time -- using ViewManager() instead of mViewManager in nsViewManagerEvent.

Comment on attachment 150470 [details] [diff] [review] patch PRBool acceptActivation; + reasonType reason; Wanna try to pack those two members into 32-bits?

This packs the struct (not that important, since it's used on the stack, but not a problem) and also restores the bizarre workaround for a bug in RevokeEvents that I recall from talkback data the first time around as being still needed. (I put it in nsViewManager.cpp's ::HandlePLEvent this time.)

Do you want review on this patch, or are you still working on it? I'd love to get this relanded soon!

I still haven't figured out the right way to handle mouse exit / enter.

So here's a rough description of the problem I'm running into: * if I listen only to mouse exit events whose widget is the root view's widget, then things don't work on Windows (bug 233374) * if I treat mouse exit and mouse enter events as toggling a boolean and don't change mMouseLocation at all, we won't handle things if the mouse is moved while over a plugin, since the view manager won't get that event. (This mainly matters for reflow, not scrolling, since most plugins seem to eat the keyboard events that we probably shouldn't be sending them in the first place (since sending key events based on mouse position is silly).) * If I use the coordinates of mouse enter events, things get off-by-one related to the amount scrolled, or sometimes just stop working completely. I've seen multiple types of behavior here, and it's not helped by the fact that sometimes we clearly do process things just fine but the cursor doesn't update (probably some sort of GTK bug). See the testcase: data:text/html;charset=us-ascii,%3Cdiv%20style%3D%22height%3A%20500px%22%3E%3C%2Fdiv%3E%0D%0A%3Ciframe%20src%3D%22http%3A%2F%2Fwww.mozilla.org%22%3E%3C%2Fiframe%3E%0D%0A%3Cdiv%20style%3D%22height%3A%20500px%22%3E%3Ca%20href%3D%22http%3A%2F%2Fwww.mozilla.org%22%3EMozilla%3C%2Fa%3E%3C%2Fdiv%3E If you scroll the page down a bit, place the mouse over the link, and then scroll the page down (so you're over the iframe) and then up, things often end up in a broken state where either the link isn't recognized at all or where things are one line off.

(My current strategy is to try to make the third approach work.)

I think many of the problem are related to two weird things that are going on: * when the mouse moves from chrome to content, the chrome VM doesn't get any indication of mouse exit, so two VMs think they're tracking the current mouse location and one of them has the wrong one * when the cursor changes, the chrome VM decides (not sure why yet) that it's necessary to synthesize a mouse move event based on the bogus location

The mouse enter and exit events seem perfectly symmetrical, as they should be. However, the events I see are: move from outside to chrome: [vm=0x88a54f8] received mouse enter for widget 0x88a56a8 move from chrome to content: [vm=0x88a54f8] received mouse exit for widget 0x88a56a8 [vm=0x88a54f8] received mouse enter for widget 0x89f3c48 [vm=0x88a54f8] received mouse enter for widget 0x8a010f8 [vm=0x880a948] received mouse enter for widget 0x8bc0a98 [vm=0x880a948] received mouse enter for widget 0x8d15648 move from outside to content: [vm=0x88a54f8] received mouse enter for widget 0x88a56a8 [vm=0x88a54f8] received mouse enter for widget 0x89f3c48 [vm=0x88a54f8] received mouse enter for widget 0x8a010f8 [vm=0x880a948] received mouse enter for widget 0x8bc0a98 [vm=0x880a948] received mouse enter for widget 0x8d15648 roc, any ideas how to tell which mouse enter events are the ones I don't want?

[vm=0x88a54f8] received mouse exit for widget 0x88a56a8 This is the top-level window. [vm=0x88a54f8] received mouse enter for widget 0x89f3c48 I think this is a widget that wraps the <browser>. Maybe it's from a tabs-related <deck>? [vm=0x88a54f8] received mouse enter for widget 0x8a010f8 I think this is the widget in <browser> that contains the primary-content subdocument. [vm=0x880a948] received mouse enter for widget 0x8bc0a98 This is the toplevel widget for the browser's subdocument. [vm=0x880a948] received mouse enter for widget 0x8d15648 This is the scroll port widget for the browser's subdocument. GTK2 isn't being very consistent here. Firing MOUSE_ENTER at all four of these widgets without any intervening EXIT seems wrong. It should probably be only firing MOUSE_ENTER on the innermost widget. This is probably a GTK2 bug. It would be interesting to see what the behaviour looks like on Mac and Windows.

This has some debugging printfs ifdef'd out. I'll test this on various platforms...

Mouse enter/exit events work the way I want on Windows (i.e., any widget that's received a mouse enter more recently than a mouse exit is the widget receiving mouse move events).

Our Mac code generates them the same way as Windows.

I think a more precise statement of what you want, and get on Windows, is that there is always at most one widget which has received a MOUSE_ENTER but not a MOUSE_EXIT, and only that widget can receive MOUSE_MOVE events. We should fix GTK2 so that's true.

This makes the gtk, gtk2, and xlib port's NS_MOUSE_EXIT and NS_MOUSE_ENTER events work the same as the windows and mac gfx ports. I didn't test the xlib changes but I tested the other two. I also stuck in my NS_PAINT_SEPARATELY diffs for GTK2. Why not? :-)

Comment on attachment 151394 [details] [diff] [review] patch okay!

Fix checked in to trunk, 2004-06-21 21:28/29/32 -0700.

This landing caused a slight Tp (pageload time) regression / increased variability. This is the patch I landed to fix that, and it seems to have worked (mostly, at least). See btek and luna tinderboxes. This also gave me the idea for bug 248226.

*** Bug 248735 has been marked as a duplicate of this bug. ***

*** Bug 252967 has been marked as a duplicate of this bug. ***

*** Bug 253043 has been marked as a duplicate of this bug. ***

Requesting blocking-aviary1.0 (this has not been ported to the Aviary branch yet). See bug 250117 for details.

Please do NOT port this to Aviary. It's just another nice-to-have but noncritical fix.

*** Bug 250117 has been marked as a duplicate of this bug. ***

*** Bug 258738 has been marked as a duplicate of this bug. ***

*** Bug 260945 has been marked as a duplicate of this bug. ***

*** Bug 261432 has been marked as a duplicate of this bug. ***

*** Bug 266377 has been marked as a duplicate of this bug. ***

*** Bug 268568 has been marked as a duplicate of this bug. ***

Interesting followup bugs (probably both related to widget code problems with NS_MOUSE_ENTER and NS_MOUSE_EXIT): bug 209565, bug 269415.

*** Bug 286113 has been marked as a duplicate of this bug. ***

*** Bug 290815 has been marked as a duplicate of this bug. ***

*** Bug 298307 has been marked as a duplicate of this bug. ***

*** Bug 98114 has been marked as a duplicate of this bug. ***

Comment on attachment 140756 [details] [diff] [review] restore code to prevent mousemoves from firing (checked in to trunk, 2004-02-06 15:10 -0800) > // 2. Give event to the DOM for third party and JS use. >- if ((GetCurrentEventFrame()) && NS_SUCCEEDED(rv)) { >+ if ((GetCurrentEventFrame()) && NS_SUCCEEDED(rv) && >+ // We want synthesized mouse moves to cause mouseover and mouseout >+ // DOM events (PreHandleEvent above), but not mousemove DOM events. >+ !IsSynthesizedMouseMove(aEvent)) { This may have caused bug 305706 and/or bug 262406. Unfortunately manager->PostHandleEvent is in this block, so that the ESM's idea of the current event frame is never cleared. If the synthesized mouse move is caused by a resize then the subsequent resize event gets erroneously targetted at the same frame instead of the document.

Comment on attachment 195196 [details] [diff] [review] sounds reasonable This fixes some regressions from a change that's happened since 1.7, and it's been on the trunk a few days.

Comment on attachment 195196 [details] [diff] [review] sounds reasonable Approved for 1.8b5 per bug meeting

Comment on attachment 195196 [details] [diff] [review] sounds reasonable Checked in to trunk, 2005-09-15 23:04 -0700. Checked in to MOZILLA_1_8_BRANCH, 2005-09-19 16:24 -0700.

*** Bug 316856 has been marked as a duplicate of this bug. ***

See also Bug 322338 for a follow-on ramification.

And see also bug 320533 for another related issue.