Closed Bug 14759 Opened 25 years ago Closed 25 years ago

[DOGFOOD] [PP] File | Close mapped to Print!!

Categories

(SeaMonkey :: General, defect, P1)

Product:
SeaMonkey
Component:
General
Platform:
Other
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: sujay, Assigned: pavlov)

References

Details

(Whiteboard: workaround avail.; Pavlov knows about this bug)

Attachments

(1 file)

patch for bug: fixes menu operation for me, little other testing done though
971 bytes, patch
Details | Diff | Splinter Review 
using 9/23 build of apprunner

1) launch apprunner and editor
2) File | Close

Printer dialog comes up!

linux only...
Assignee: buster → akkana
Assignee: akkana → hangas
Component: Editor → Browser-General
This has been reported on the browser, too.  Not an editor issue.  I'm not
seeing it on my Linux build from this morning, so it may have been something
checked in more recently than that.
FYI: Here's the editor's command routing:
Triggered by the menu -- EditorOverlay.xul:
      <broadcaster id="Editor:Close"        value="&closeCmd.label;"
disabled="false"  oncommand="EditorClose()"/>

And this is the command handler in EditorCommands.js:
function EditorClose()
{
  dump("In EditorClose...\n");
  editorShell.CloseWindow();

in nsEditorShell.cpp:
NS_IMETHODIMP
nsEditorShell::CloseWindow()
{
  nsresult rv = NS_OK;
  PRBool result;
  rv = CheckAndSaveDocument(&result);
Assignee: hangas → sspitzer
I was able to see this happen but when attempting to debug issue with Seth the
problem went away.  Seth is taking this off my hands.
Move milestone stoppers to M10
Bug 14690 should be duplicate of this bug.
*** Bug 14690 has been marked as a duplicate of this bug. ***
bug #14690 was marked P1,
this one is only P3.
shouldn't this one be the same?
Assignee: sspitzer → don
re-assign to don.

I'm focusing on the profile manager right now, but this needs to be fixed.

pavlov, don, mcafee:  can one of you XP apps people take this?
Priority: P3 → P2
High visibility, P2.
Assignee: don → law
Bill, since you have an M10 branch ...
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Unable to reproduce the problem on two separate Linux boxes.  I suspect this was
temporary problem that has already been resolved.
Status: RESOLVED → REOPENED
Assignee: law → mcafee
Status: REOPENED → NEW
no way, I can reproduce this easy.
Reopening & stealing.
Resolution: WORKSFORME → ---
*** Bug 15113 has been marked as a duplicate of this bug. ***
mcafee, you suck, and are on drugs.  ;-)
no one else can see this.  lets get this off the m10 list.
Whiteboard: mcafee is the only person in the world that see this.
Whiteboard: mcafee is the only person in the world that see this. → mcafee is the only person in the world that sees this.
Whiteboard: mcafee is the only person in the world that sees this.
syd reproduced this in the dup, clearing whiteboard status.
Assignee: mcafee → pavlov
I figured out how to reproduce this.
If you click your way to File|Close, the menu works.
If you DRAG your way to File|Close, you get the menu
just before quit, which is Print in this case.

pavlov or hyatt.
ok, good work,
does "click, don't drag" in m10 release notes sound ok?
I think release-noting this would be good enough
to push this to m11, it's gonna be a bug for other
menus too, so let's not push it back past m11.
That said, I think we should take a fix for m10 if
we have one.
Target Milestone: M10 → M11
Will Release Note for M10, moving to M11.
*** Bug 15639 has been marked as a duplicate of this bug. ***
QA Contact: sujay → cpratt
*** Bug 15697 has been marked as a duplicate of this bug. ***
*** Bug 16142 has been marked as a duplicate of this bug. ***
Severity: normal → major
Priority: P2 → P1
Too many dups, marking P1.
Summary: [PP] File | Close mapped to Print!! → [DOGFOOD] [PP] File | Close mapped to Print!!
adding saari.

marking a dogfood bug.

when using messenger, we have "Edit | Preferences..." followed by "Edit |
Account Setup..."

"Account Setup..." is the last choice under the edit menu.

when this bug rears its ugly head, "Account Setup..." does nothing, and
"Preferences..." does what "Account Setup..." should have done.
Whiteboard: workaround avail.; Pavlov knows about this bug
Folks, buy me a virtual beer.  After enduring a painful "gdb" session and my
girlfriend's angry glares, I tracked this one down.

The problem is in gtk/nsWidget.cpp.  If sButtonMotionTarget is active,
OnButtonReleaseSignal changes the destination widget of the mouse-up event but
doesn't do the origin fixup for the event.point.  For example, when you drag
down a menu and release on a menu item, the event.widget on the mouse-up event
gets changed from the popdown menu to the menubar button, so the position of the
event is effectively shifted upwards by the size of the menubar button.

See the previous attachment for a patch.
Cool!  This seems to work for me.  Waiting for checkin window (tree is
red right now).  Virtual beer is on the way, I think a
Guiness is in order :-)
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
fixed
*** Bug 15932 has been marked as a duplicate of this bug. ***
Status: RESOLVED → VERIFIED
works for me using the 1999101908 build, linux.
*** Bug 18061 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: