Closed Bug 105698 Opened 23 years ago Closed 23 years ago

context menu repositioned when tooltip displays

Categories

(Core :: XUL, defect)

defect
Not set
normal

Tracking

()

VERIFIED WORKSFORME
mozilla1.2alpha

People

(Reporter: dean_tessman, Assigned: hewitt)

References

Details

(Whiteboard: [adt3 rtm])

Attachments

(1 file)

This is a cool one, kinda. 1. Open a context menu on any page. 2. Hover over something on the toolbar until a tooltip displays Expected results: They live in perfect harmony. Actual results: Context menu is repositioned higher up. It only gets repositioned vertically, though, the horizontal position never changes.
Build ID:2001101603 on Win2K
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0.1
see this with 0.9.8 on w98. also, when you mouse-off the area which gave the tooltip, the context menu jumps up and to the left.
*** Bug 112750 has been marked as a duplicate of this bug. ***
Bug 112750 was for OS X. --> All/All
OS: Windows 2000 → All
Hardware: PC → All
*** Bug 115158 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.0, nsbeta1
claudius pointed out that this is particularly a problem on Mac with the click-and-hold context menu when trying to use the context menu on an anchor with at title attribute (which is a tooltip, for example in bugzilla pages). You just get the context menu up and then the tooltip also fires, moving the context menu away and giving the user the "let's back away slowly" kind of low confidence feeling.
Severity: minor → normal
Target Milestone: mozilla1.0.1 → ---
nsbeta1- per Nav triage team, ->1.2
Keywords: nsbeta1nsbeta1-
Target Milestone: --- → mozilla1.2
*** Bug 129874 has been marked as a duplicate of this bug. ***
*** Bug 131982 has been marked as a duplicate of this bug. ***
I run into this all the time. Easy (and common) way to reproduce: 1) Right-click in URLbar 2) Move mouse over "copy" 3) Wait a second 4) Click Actual results: Whatever is in the clipboard is *pasted* into the URLbar. No copy takes place. ugh!
WD: filed bug 133788 because the URL bar context menu shouldn't have a tooltip.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Added myself as a CC to "this" bug. I am using Windows NT 4.0 SP6a with all post SP6a Fixes/Hot Fixes applied, and Mozilla 0.9.9-2002031104. I concurr "this" bug for moving context menu exists for 0.9.9-2002031104 Win32. My experiences can directly relate to: 1) Initial bug report of "this" bug. 2) Comment #2, but in my case NT 4.0 3) Comment #8 aka Bug 129874, exactly as I have but with NT 4.0 4) Comment #10, but in my case NT 4.0 The shifting of the right context menu is a real pain and can lead to the "wrong" context menu being selected as a result of this moving context target. That has also been noted in the other comments above at times and some of the bugs marked as duplicates of "this" bug. I do not know if anyone has noticed but the context moves more than once so even when aware of the behaviour it is still a cat and mouse chase to select the menu item at times. I like that fact there are seperate bugs, one for menu shifting and one for tool tips. (I am just not sure if one causes other or they are different unrealted cause and effect issues, but safer to make seperate bugs.) -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com> Comment: . iQA/AwUBPKu0+PLzhJbmoDZ+EQJkoACg+NL1N65dChTilg6tD0JRbTYJeG0AoMng axG8shxxonfDc5RXSEOmdBvK =KLvJ -----END PGP SIGNATURE-----
Not sure it's correct, but it fix situation.
Tested Sergi's patch, and it does indeed fix this bug.
Adding correct keywords
Keywords: patch, review
*** Bug 137681 has been marked as a duplicate of this bug. ***
Comment on attachment 79291 [details] [diff] [review] Patch that does not make reposition for alredy active menus. Two niggles: 1. Indentation looks wrong. 2. Wrong if style, should be if (value != ...("true")) RepositionPopup(...);
Okey, but I do not wait for review, it's just a question about correctness. Patch really has a problem. While we hide these popup (context menu), we'll call reposition with wrong conditions, because we'll have activemenu set to "false". It leads to blinking of context menu in wrong place just before disappearing. So, I just looking for advice.
Sergi: any chance that's bug 103069?
Sure, bug 103069 is exactly thing I talk about. I guess, both bugs have the same reason, and this reason is calling of repositioning procedure in cases we should not. So, we can consider such behaviour as two different bugs. But also we can close 103069 as dup of this bug and fix all cases of shifts. If we'll choose second way, we should change summary to "popup menu shifts while show tooltips or dismissal". What do you think?
Let's keep them separate to make sure we track both issues. But feel free to mark the other as a dupe of this if you want to fix both of them at one time.
*** Bug 139235 has been marked as a duplicate of this bug. ***
*** Bug 139622 has been marked as a duplicate of this bug. ***
*** Bug 140093 has been marked as a duplicate of this bug. ***
*** Bug 142010 has been marked as a duplicate of this bug. ***
*** Bug 142359 has been marked as a duplicate of this bug. ***
*** Bug 142353 has been marked as a duplicate of this bug. ***
RC2 seems to no longer have this bug. I can't reproduce it.
Unlike the 2002-05-12 03:16 comment from another, I still get this bug on RC2. To be more specific, I still get the context menu repositioning vertically, to the point where it cannot be used as a click target, in RC2 build 2002051006.
confirmed, still happens for me in rc2
I don't see this anymore on build 2002051908-trunk, win98.
I second that. WFM Trunk Win2k 2002052104
its gone from 1.0 branch 2002051906 win2k too!!! :-D
I confirm this on WinXP. This bug is fixed. Should I mark it FIXED or WORKSFORME?
->hewitt, renominating for MachV
Assignee: hyatt → hewitt
Status: ASSIGNED → NEW
Keywords: nsbeta1-nsbeta1
Probably fixed by patch for bug 143607
Nav triage team: nsbeta1+, adt3 rtm
Keywords: nsbeta1nsbeta1+
Whiteboard: [adt3 rtm]
Huh?? There's no fix for this bug, and it's working now for people. Marking WORKSFORME based on the various comments.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
v
Status: RESOLVED → VERIFIED
*** Bug 137529 has been marked as a duplicate of this bug. ***
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: