168065 - context menu persists even after another page loads

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: Toolbars & Menus, defect)

Description

[sairuh (rarely reading bugmail)]

found using 2002.09.11.05. if i bring up a context menu right after clicking a
ling to load, that menu persists even after the target page loads. i noticed
this while talking to chris about bug 168051.

1. go to http://chimera.mozdev.org/installation.html
2. click on the "bugs" link.
3. before the target page loads, bring up the context menu (control-click) for
the "bugs" link.
4. keep the context menu open (you can hover it, but don't click to select
anything or dismiss it) and wait for the target page to load.

a. result: the context menu remains open

5. select an item in the context menu, eg, "open link in new tab"

b. result: the target of "bugs" will load in a new tab --the context menu is
still based on the content of the previous page (step 1), instead of the now
current page (step 4).

what should the expected behavior be here?

we noticed that this also occurs in netscape (recent trunk). however, in IE on
OS X, if i keep the context menu up, the target page *stops* loading until i
either dimiss or select a context menu item.

how about this: if we should continue page load while the context menu is
present, okay, but once the target page finishes loading, shouldn't the context
menu go away?

Comment 1

[Mike Pinkerton (not reading bugmail)]

-> brade for a look

Comment 2

[Kathleen :Brade]

-->pinkerton

Comment 3

[Samuel Sidler (old account; do not CC)]

Ping.

Status update? I checked Safari and, like IE/Mac, it also stops loading the
target page until the context menu is dismissed. I agree with this approach. Any
thoughts?

Comment 4

[Håkan Waara]

If I understand this right, these are the steps to reproduce:

1. Click a link
2. Control-click it again, before the page goes away.

You get a context-menu. You can use its items like "Open in New Window", etc.

I don't think it would be reasonable to stop the loading (step #1) in its tracks just because you are quick enough to bring up a context menu (#2). I'm also a bit reluctant that the context menu would somehow be invalid, just because the page under it changed.

If I understood the bug right, I think this should be WFM/invalid.

Comment 5

[Stuart Morgan]

This is definitely not invalid. Either the context menu needs to go away, or the loading needs to be temporarily suspended; anything else leaves a menu whose behavior is not at all clear.

Comment 6

[Chris Lawson (gone)]

(In reply to comment #3)

> Status update? I checked Safari and, like IE/Mac, it also stops loading the
> target page until the context menu is dismissed. I agree with this approach. Any
> thoughts?

This is what current trunk nightlies seem to do now. I can't get the underlying page to load until dismissing the CM if I trigger the CM after clicking a link. So this seems fixed, but by what? Was there a Core change that solved this problem?

cl

Comment 7

[Stuart Morgan]

I'm seeing trunk fixed as well. Perhaps there were event changes that caused loading to be a runloop source in a mode that's ignored in the context menu tracking mode?

Josh, do you know of anything like that that was done on the trunk?

Comment 8

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I'd guess mento changed this when he implemented thread mgr.

Comment 9

[Chris Lawson (gone)]

Are we going to try to fix this on the 1.x branch at all, or are we just gonna call it fixed for 2.0 (which it definitely is)?

Comment 10

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Right now this being "fixed" on the trunk is merely a symptom of bug 356720, since clicks to any native stuff (menus, scrollbars, context menus) stops Gecko entirely.

Comment 11

[Chris Lawson (gone)]

Yeah, this is still broken on trunk (tested with 2007100900 nightly) now that bug 356720 is fixed. It's pretty ugly behaviour, too, although getting it to happen requires some pretty good timing that minimises the severity, IMO. (It's unlikely users are running into this on a regular basis, IOW.)

Comment 12

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

philippe noted (after he and I commented in bug 574842) that <select> menus also experience this issue.

I don't know what sort of information we get from Gecko, but it seems like in theory we could fix this by listening for whatever the "navigation start" event is and then telling these menus to close, just like we close menus when sheets or dialogues appear.

(My preference is for closing the menu rather than cancelling the navigation, because the latter reminds me too much of the bad old days when mouse-clicks stopped all event processing.)

Safari also has this bug, and it does nothing except make the progress bar (location bar background blue stuff) not progress on the new page; other than that, the new page loads and the stray menu remains :P