Autocomplete pop-up remains in place while parent window dragged

RESOLVED FIXED in mozilla0.9.9

Status

SeaMonkey
Autocomplete
P5
normal
RESOLVED FIXED
17 years ago
14 years ago

People

(Reporter: Greg K., Assigned: Mike Pinkerton (not reading bugmail))

Tracking

Trunk
mozilla0.9.9
PowerPC
Mac OS X

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

5.15 KB, patch
Mike Pinkerton (not reading bugmail)
: review+
Simon Fraser
: superreview+
Details | Diff | Splinter Review
(Reporter)

Description

17 years ago
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.
->autocomplete?
Assignee: pchen → hewitt
Component: XP Apps → XP Apps: Autocomplete
QA Contact: sairuh → blakeross

Updated

17 years ago
Status: NEW → ASSIGNED
Priority: -- → P5
Target Milestone: --- → Future

Updated

17 years ago
Blocks: 102998

Comment 2

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

Comment 3

17 years ago
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

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

Comment 5

17 years ago
Created attachment 66149 [details] [diff] [review]
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

17 years ago
Please see comment 5 if you get a chance.
(Assignee)

Comment 7

17 years ago
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

17 years ago
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.

(Assignee)

Comment 9

17 years ago
a-ha, you're right. i forgot they were in different classes. ok, makes sense.
Assignee: hewitt → pinkerton
Status: ASSIGNED → NEW
Keywords: mozilla0.9.9, nsbeta1, patch
Target Milestone: Future → mozilla0.9.9

Comment 10

17 years ago
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?
(Assignee)

Comment 11

17 years ago
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

17 years ago
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?
(Assignee)

Comment 13

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

Comment 14

17 years ago
nsbeta1- per ADT triage team
Keywords: nsbeta1 → nsbeta1-
(Assignee)

Comment 15

17 years ago
*** Bug 19974 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 16

17 years ago
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.
Status: NEW → ASSIGNED

Comment 17

17 years ago
changing qa to claudius.
QA Contact: blaker → claudius

Comment 18

17 years ago
Setting back to nsbeta1 - this bug is on the list of ones identified as needing
fixing to make MachV a better Mac citizen.
Severity: trivial → normal
Keywords: nsbeta1- → nsbeta1
(Assignee)

Comment 19

17 years ago
ugh, the patch doesn't apply anymore. i'll try to get a new one up.
(Assignee)

Comment 20

17 years ago
Created attachment 70075 [details] [diff] [review]
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?
Attachment #66149 - Attachment is obsolete: true
(Assignee)

Updated

17 years ago
Attachment #70075 - Flags: review+

Comment 21

17 years ago
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
Attachment #70075 - Flags: superreview+
(Assignee)

Comment 22

17 years ago
fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.