Closed Bug 65014 Opened 24 years ago Closed 24 years ago

Extra "Save As..." and Separator in navigator context menu

Categories

(Core :: XUL, defect)

defect
Not set
minor

Tracking

()

VERIFIED FIXED

People

(Reporter: stdowa+bugzilla, Assigned: bugzilla)

References

Details

(Keywords: regression)

Attachments

(1 file)

Using the 2001011004 nightly on win2k, there are 2 separators above Save As in 
the navigator context menu, where there should only be one. Assigning to morse 
since blake thinks morse forgot to hide the extra separator that separated 
prefill form and save form data.
No, I haven't changed anything here in a while.  Furthermore, I'm unable to 
reproduce this bug.

Reassigning to Bill Law since he handles context menu.
Assignee: morse → law
I can reproduce this.  There's also two "Save As..."'s.  will look into it later
Keywords: nsbeta1, regression
resummarizing based on Blake's comments
Summary: Extra separator in navigator context menu → Extra "Save As..." and Separator in navigator context menu
*** Bug 65046 has been marked as a duplicate of this bug. ***
*** Bug 65776 has been marked as a duplicate of this bug. ***
I checked some old builds.  The menu works correctly in 2001-01-09-08 and before
is broken in 2001-01-09-21 and after.

I suspect that ben's checkin to fix bug 56719 and bug 57108 may be causing this.

*** Bug 65776 has been marked as a duplicate of this bug. ***
Looking at it, basically looks like the entire context menu is duplicated --
those two separators are the two separators in that menu that are never removed,
and that option is the one option that is never removed.
I don't know enough about how deep merging works to understand why this patch 
seems to fix the problem.  Ben, thoughts?
*** Bug 65946 has been marked as a duplicate of this bug. ***
OS: Windows 2000 → All
Hardware: PC → All
*** Bug 66179 has been marked as a duplicate of this bug. ***
*** Bug 66179 has been marked as a duplicate of this bug. ***
Well, this fix doesn't hurt anything and this is annoying, so I'd like to get 
this in until Ben and I can figure it out.
*** Bug 67544 has been marked as a duplicate of this bug. ***
alec, sr?
r=timeless
Assignee: law → blakeross
sr=alecf
>I don't know enough about how deep merging works to understand why this patch 
>seems to fix the problem.  Ben, thoughts?

How can a patch with such a comment get a r and a sr? I thought that the review
guidelines describe a slightly different mechanism. Could somebody explain, why
the patch is good and will not cause regressions. I think this would help also,
if later, one has to return to this bug and all the intentions, that are now
clear, may be difficult to understand without explanation.
Because the patch is completely harmless.  It just changes the id of one 
menuitem (that isn't used anywhere else), and adds id's to two separators.  I 
checked in that workaround, and now I'll leave this open to eventually figure 
out why this happened.  It may, as Ben said, just have been bad use of xul and 
overlays (a menuitem and a popup menuitem needlessly sharing the same id).
Severity: normal → minor
Status: NEW → ASSIGNED
Keywords: nsbeta1
Severity: minor → normal
Keywords: nsbeta1
http://lxr.mozilla.org/seamonkey/search?string=context-savepage

/xpfe/browser/resources/content/navigatorOverlay.xul, line 166 -- <menuitem 
id="context-savepage" key="key_savePage"
observes="Browser:SavePage"/>
/xpfe/communicator/resources/content/nsContextMenu.js, line 106 -- 
this.showItem( "context-savepage", !this.inDirList );
/xpfe/communicator/resources/content/contentAreaContextOverlay.xul, line 125 -- 
<menuitem id="context-savepage"
--
Giving separators id's is harmless, splitting the id's for the save as item is 
odd, but if blake promises to continue to investigate then it's not a big deal.
Severity: normal → minor
Keywords: nsbeta1
Looks fixed in build 2001020504.
yes...interesting... appears fixed to me as well [2001.02.05.xx on winnt and
mac, 2001.02.07.12 on linux]. blake, was something else checked in? should this
be marked resolved...? thx!
I checked in the workaround, but want to leave this open to figure out why it 
happened at all.
This fix was fine, and since it's generally a Bad Thing to have two nodes with 
the same id's, I don't think further investigation is needed here. Marking 
fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
verifying
Status: RESOLVED → VERIFIED
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: