Closed Bug 61955 Opened 24 years ago Closed 20 years ago

watch cursor displayed in plugin menus and dialogs

Categories

(Core Graveyard :: Plug-ins, defect, P3)

PowerPC
Mac System 9.x
defect

Tracking

(Not tracked)

RESOLVED WONTFIX
Future

People

(Reporter: sean, Assigned: peterlubczynski-bugs)

References

()

Details

(Keywords: polish, Whiteboard: [PL2:NA])

Attachments

(2 files)

Moz/n6 switches the mouse cursor from the standard arrow to the watch when 
plugins display dialogs or menus.

Test by going to http://www.flash.com and Ctrl+clicking on the flash 
animation.  About 2 or 3 seconds after the menu appears, the cursor changes.
CCing Pinkerton.
i guess before we send the event into the plugin, we need to turn off the watch
cursor, and turn it back on again when we come out from delivering the event.

look at what i did to turn it off in other areas of the mac widget code.
Petersen, is this a dup or the one you were looking for?
Moving to m1.0 and reassigning to sean. sean, if you can't fix this for m1.0, 
please reassign to peterl.
Assignee: av → sean
Target Milestone: --- → mozilla1.0
attached patch for the change that Mike suggested - wrapped the ProcessEvent 
call with nsWatchTask::GetTask().Suspend()/nsWatchTask::GetTask().Resume()

The patch relies on a change to the mac project - need to add /gfx/src/mac to 
the path list. nsObjectFrame.cpp now includes nsWatchTask.h from the 
gfx/src/mac directory.

Would appreciate it if someone more mac-savvy could handle that end of the 
checkin.

I couldn't get a full-page plugin to work on my mac - the attached patch may 
not address the problem for full-page plugins.

review please.
Just thought of something.  The patch only addresses mouse invoked actions 
(clicking on a plugin to display a menu or dialog).  It does not address a 
situation like invoking a plugin's 'About' dialog via javascript :(
oh well. i can check this in if you'd like. should i then leave the bug open?
You can try your patch with my full page plugin patch in bug 35682.

Is there something similar to pluginSaftey on the Mac which can trap an OS 
exception. It'd be nice to have this like on Windows.
no, you can't (humanely) trap processor exceptions in c++ on mac.
How does LiveConnect know to invoke if a crash happens?
I don't follow the question.  LiveConnect (in the plugin sense) is no longer 
supported.
re: full-page plugins, the attached patch does not address them.  But it can be 
reviewed and checkedin (along with a modified codewarrior project file) 
independently of the fullpage case.
Sean,

Are you seeking review for your patch?
he sure is, i'm just swamped and haven't r='d it yet (he's in the queue, but near 
the middle)
Mike/Sean, what's the status of this bug?
waiting for review
Keywords: review
does this compile? i don't think that nsWatchTask is exported to dist, and 
layout.mcp doesn't look in gfx in the include paths. (my tree is in shambles 
right now, so i can't check).
The patch requires a change to the mac project to get nsWatchTask.h - need to 
add /gfx/src/mac to the path list.  At least that's what I did - I don't know 
if it would be better to change the gfx to export nsWatchTask.h to dist.

I won't be able to checkin that part of the change and will need a mac person 
to take care of it.
no, let's export nsWatchTask.h from gfx. i don't like adding access paths.
Move up milestone as this is annoying and ugly.

Pinkerton, correct me if I'm wrong, but the only thing left to do on this bug is 
export nsWatchTask.h in the MANIFEST file? If that's all, pending a full patch 
is attached, can we get your s/r=?
Keywords: patch
Whiteboard: [seeking review]
Target Milestone: mozilla1.0 → mozilla0.9.2
sure. r=pink with appropriate manifest changes.
Reassigning to Peter.  I won't be able to finish this up.  Needs manifest
changes before it can go in.
Assignee: sean → peterlubczynski
Keywords: review
Whiteboard: [seeking review] → [fix-in-hand][d:1]
Exporting nsWatchTask.h sounds like the wrong way of going as it's a private
class in gfx. cc:ing Don Cone for his input.

I think there is a better way of changing the cursor on the Mac then going so
low level. Isn't there a constant for telling the plugin to change the cursor?
I'm not sure, cc:ing Brian Nesse.

Also moving off to mozilla 0.9.3 as I don't think this is a beta stopper.
Status: NEW → ASSIGNED
Keywords: patchpolish
Whiteboard: [fix-in-hand][d:1]
Target Milestone: mozilla0.9.2 → mozilla0.9.3
it's not that private, we use it all over in widget. it's only in gfx so the
print stuff has access to it.

i think it's ok to export it.
I don't know of any built in method for telling a plugin what the cursor should
be or that it's time to change. I would assume that the plugin would be
responsible for the cursor while it's over the plugin and the browser would be
responsible at all other times.

Why are we going to the watch cursor anyway? If you control click on a normal
page we don't go to a watch cursor.

Another good example of this is to go to one of the Qubic VR movies at Apple's
website.

http://www.apple.com/quicktime/products/gallery/church.html

First, note that the movie controls the cursor when the mouse is over the movie
frame. Next, if I control click on the movie, it pops up the Quicktime context
menu. When I click to dismiss that... I get the watch cursor, followed by our
context menu... this is just patently wrong. Clicks in the plugin should only be
handled by the plugin.

I think that we are working on a symptom, not the real problem here.
argh. this is a dead snake. we get the watch because when we go into the OS to
handle a modal dialog or track an OS context menu we're away from the event loop
so our VBL watch task kicks in.

just turn off the watch cursor before going into plugin code and we're fine. the
patch is good.
Exporting nsWatchTask is going to need some moving of CVS files. Plugins already
depend on gfx, can I just fix up the plugin project file to include gfx like
Widget does without touching gfx?

can't you just put in a manifest file and export it to dist?
http://lxr.mozilla.org/seamonkey/source/gfx/src/mac/nsWatchTask.h

...isn't public. There is no MANIFEST. Wouldn't I have to "move" it to the
"public" folder?
or just add a manifest from gfx/src/mac. there's nothing special about 'public'.

but, if that makes you feel nasty (we do it everywhere, not sure why it would), 
you can add an access path into gfx. six of one, right?

smfr? have an opinion here?
Just export nsWatchTask.h from gfx. It would be nice if it was in a public folder 
(just remove and re-add; there isn't much revision info we care about), but I 
don't care too much. It's not a public interface.
Pinkerton & Simon, can I get your final blessing on the last patch attached in
this bug? Thanks!
Keywords: patch
Whiteboard: [SEEKING REVIEWS]
You'll also need to edit MozillaBuildList.pm to add your new MANIFEST file so the 
list.
Hm...I updated my tree and fixed up MozillaBuildList.pm, but now this doesn't
seem to work. I get a currupt cursor now. Pushing off to mozilla0.9.4.
Whiteboard: [SEEKING REVIEWS]
Target Milestone: mozilla0.9.3 → mozilla0.9.4
*** Bug 95909 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Depends on: 52108
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Target Milestone: mozilla0.9.8 → mozilla1.0
nominating nsbeta1
Keywords: nsbeta1
Minusing, setting to 1.2
Keywords: nsbeta1nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.2
Whiteboard: [PL2:NA]
Target Milestone: mozilla1.2alpha → mozilla1.3alpha
Classic only --->future
Target Milestone: mozilla1.3alpha → Future
This bug is targeted at a Mac classic platform/OS, which is no longer supported
by mozilla.org. Please re-target it to another platform/OS if this bug applies
there as well or resolve this bug.

I will resolve this bug as WONTFIX in four weeks if no action has been taken.
To filter this and similar messages out, please filter for "mac_cla_reorg".
Mac classic only. Marking WONTFIX
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: