99987 - Autocomplete pop-up remains in place while parent window dragged

Status: RESOLVED FIXED

(SeaMonkey :: Autocomplete, defect, P5)

Description

[Greg K.]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.4) Gecko/20010913
BuildID:    2001091313

When an autocomplete pop-up is visible on a Navigator window and the window is
dragged, the pop-up remains stationary.

Reproducible: Always
Steps to Reproduce:
1. Open a Navigator window
2. Type some text in the URL field to summon the autocomplete pop-up
3. Drag the Navigator window around.

Actual Results:  The autocomplete pop-up remains displayed in its' last position.

Expected Results:  The autocomplete should either dismiss prior to beginning
window drag, or should be dragged along with the window.

There is some similarly strange behavior under Mac OS 9 when a full-window drag
utility such as Power Windows is installed. If the autocomplete pop-up is
visible and the window is dragged around, some crumbs from the old autocomplete
pop-up's border can be seen behind the window.

Comment 1

[sairuh (rarely reading bugmail)]

->autocomplete?

Comment 2

[Joe Hewitt (gone)]

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

Comment 3

[Ari]

This is not a trivial bug because it is actually a special case of larger
problem. All popups (comboboxes, xul popups, XP menus, etc.) remain in place
while the parent window is dragged and only roll up when the mouse button is
released and the drag is completed.

I am not sure but I think the reason for this is that in
nsMacWindow::HandleMouseDownEvent() in the following code for dragging windows

case inDrag:
{
  Point macPoint;
  Rect portRect;
  ::GetWindowPortBounds(whichWindow, &portRect);
  macPoint = topLeft(portRect);
  ::LocalToGlobal(&macPoint);
  mTopLevelWidget->MoveToGlobalPoint(macPoint.h, macPoint.v);
  if (nsnull != gRollupListener && (nsnull != gRollupWidget) ) {
    gRollupListener->Rollup();
  }
  break;
}

popup menus are rolled up after the drag not before as they should be.

I think that this bug should be assigned to a mac person because it is a mac
windowing issue not an autocomplete issue.

Comment 4

[Ari]

Maybe a similar problem exists on the platforms mentioned in bug 95254

Comment 5

[Ari]

Attachment: incomplete patch

This patch causes popups to disappear when window drags begin and when windows
are minimized. This is the OS default behavior.

There are two problems:
1. Popups are rolled up when windows are dragged, but when they have a button
associated with them, that button remains pressed even though the menu is gone.
For example, open the bookmarks menu by clicking on the toolbar button. Note
that when this patch is applied, the menu disappears, but the bookmarks toolbar
button remains pressed.

2. This patch makes yet another change to the installation of a the Carbon
window event handler in nsMacWindow::StandardCreate(). I needed to do this
because I think you can only call IWEH() once for each event class so our
current system of making multiple calls to IWEH() inside conditionals won't
work as we add more events to the handler. I don't think this harms anything
because we check for the proper conditions inside the handler proc anyway.

Comment 6

[Ari]

Please see comment 5 if you get a chance.

Comment 7

[Mike Pinkerton (not reading bugmail)]

where does it say we can only call IWEH once per event class? we're calling it
multiple times now (to add scrolling and live resize) and it seems to work just
fine.

Comment 8

[Ari]

I'm not sure where/if it says this, but in ths case scroll events are of
kEventClassMouse whereas window events are of kEventClassWindow. What I meant to
say is that I don't think you can call IWEH() twice on the same target with the
same event class. I tried it and the second call fails. I think you have to use
AddEventTypesToHandler(), which requires us to get an EventHandlerRef from
IWEH() which means that the EventHandlerRef won't be disposed of automatically
as it is now.

Comment 9

[Mike Pinkerton (not reading bugmail)]

a-ha, you're right. i forgot they were in different classes. ok, makes sense.

Comment 10

[Ari]

I think that the reason why the bookmarks button looks like it is pressed is
because it's not being repainted. What's the best way to force a repaint?

Comment 11

[Mike Pinkerton (not reading bugmail)]

from line 585 of nsMacMessagePump, we force a repaint by faking an update event

nsCOMPtr<nsIWidget> topWidget;
nsToolkit::GetTopWidget ( whichWindow, getter_AddRefs(topWidget) );
nsCOMPtr<nsIEventSink> sink ( do_QueryInterface(topWidget) );

EventRecord updateEvent = anEvent;
updateEvent.what = updateEvt;
updateEvent.message = NS_REINTERPRET_CAST(UInt32, whichWindow);
sink->DispatchEvent ( &updateEvent, &handled );

it's a hack, but give it a try.

Comment 12

[Ari]

I jsut tried this method of repainting and it doesn't work that well. It
introduces a delay in dragging when a popup needs to be rolled up prior to a
drag. It also doesn't repaint the bookmark button icon for some reason. Would it
be better just to table the repaint problem until CarbonEvents save the day?

Comment 13

[Mike Pinkerton (not reading bugmail)]

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

Comment 14

[Peter Trudelle]

nsbeta1- per ADT triage team

Comment 15

[Mike Pinkerton (not reading bugmail)]

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

Comment 16

[Mike Pinkerton (not reading bugmail)]

what's our status here? should we just try to get this patch checked in as-is
and then fix any little niggles that appear? we're running out of time on 099.

Comment 17

[Blake Ross]

changing qa to claudius.

Comment 18

[Steve Dagley]

Setting back to nsbeta1 - this bug is on the list of ones identified as needing
fixing to make MachV a better Mac citizen.

Comment 19

[Mike Pinkerton (not reading bugmail)]

ugh, the patch doesn't apply anymore. i'll try to get a new one up.

Comment 20

[Mike Pinkerton (not reading bugmail)]

Attachment: updated patch

this updated patch looks fine to me. we can certainly live with the buttons not
updating until the mouse is released. i have no problem with that.

r=pink. simon, can you sr?

Comment 21

[Simon Fraser [no longer active]]

Comment on attachment 70075 [details] [diff] [review]
updated patch

Make this data const:

+    EventTypeSpec windEventList[] = {
+				       {kEventClassWindow,
kEventWindowBoundsChanged}, // to enable live resizing
+				       {kEventClassWindow,
kEventWindowCollapse},	    // to roll up popups when we're minimized
+				       {kEventClassWindow,
kEventWindowConstrain}	    // to keep invisible windows off the screen

and sr=sfraser

Comment 22

[Mike Pinkerton (not reading bugmail)]

fixed.