Closed Bug 62722 Opened 24 years ago Closed 23 years ago

[Modern] Editable menulists not implemented

Categories

(SeaMonkey :: Themes, defect, P2)

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.4

People

(Reporter: morse, Assigned: hewitt)

References

Details

(Keywords: modern)

Now that the new wallet UI has landed, editable menulists need to be hooked up 
in all skins.  Currently they have been implemented in classic skin only.

To demonstrate do the following:

1. With classic skin, select menu item
      task->privacy->form-manager->view-captured-form-data
2. Select any of the menulists in the dialog and enter some text
3. Drop down the menulist and select the blank entry
4. Enter more text
5. Repeat 3 & 4 at least one more time
6. Click on OK to exit the dialog
7. Switch to modern skin
8. Repeat step 1

Note that at this time the menulists appear but they have no little icon to 
allow you to drop down the menu.  There is no way to change the selected menu 
item.
*** Bug 62764 has been marked as a duplicate of this bug. ***
skin switching? over to skinability...unless it's modern-specific, then pls over
to themes. :)
Component: XP Apps → Skinability
QA Contact: sairuh → blakeross
This has nothing to do with skin switching -- I used a skin switch in my steps 
above just to demonstrate that it works in one skin and not the other.

The problem here is that editable menulists are new and have not yet been fully 
implemented.  They have been implemented in classic skin and now need to be 
implemented in the other skins as well.
Component: Skinability → XP Toolkit/Widgets
QA Contact: blakeross → jrgm
errr...sorry, didn't read closely enough.  ->hewitt
Assignee: ben → hewitt
Component: XP Toolkit/Widgets → Themes
QA Contact: jrgm → pmac
I saw this today on linux also..commercial build 2000-12-18-06-Mtrunk
I also saw this today on Mac in classic skin...commercial build 
2000-12-18-08-Mtrunk
OS: Windows NT → All
Hardware: PC → All
Status: NEW → ASSIGNED
seeing this in classic skin on linux commercial build 2000-12-22-06-Mtrunk

changing summery and upgrading to blocker
Severity: normal → blocker
Summary: Editable menulists do not work in modern theme → Editable menulists do not work
This bug is getting confusing.  I initially reported it as a bug in modern skins 
and the reason there is obvious -- editable menulists have not yet been 
implemented for anything other than modern.  Terri then went and reported some 
problems with classic skin on mac and linux.  This is an unrelated problem and 
should be covered in a separate bug report.  In fact there is a separate bug 
report on such issues, namely 63616, and that should be used for problems with 
classic skin on non-windows platforms.

Adding the skin qualification back to the summary line.
Summary: Editable menulists do not work → Editable menulists do not work in other than classic skin
Keywords: nsbeta1
Keywords: newmod
Summary: Editable menulists do not work in other than classic skin → Editable menulists don't work in any themes except Classic
so, this is a skin-parity issue (RFE), with a workaround. I argue that this
shouldn't block the tree. if someone on the bug cares to second, i'll downgrade
the severity.
Correction:

In my December 22 comment I wrote:

   editable menulists have not yet been implemented for anything
   other than modern

Of course I meant to say

   editable menulists have not yet been implemented for anything
   other than *classic*
Priority: P3 → P1
Summary: Editable menulists don't work in any themes except Classic → [Modern] Editable menulists not implemented
Marlon is going to design the graphics for editable menulists sometime this week
or next, and then we'll be in business.
Themes Triage Team nsbeta1+
Target Milestone: --- → mozilla0.9
*** Bug 66699 has been marked as a duplicate of this bug. ***
*** Bug 66732 has been marked as a duplicate of this bug. ***
Keywords: newmodmodern
For clarification, this bug is about editable-menulists never having been 
implemented in any theme other than classic.  So it's a feature that was never 
completely implemented.  Whereas bug 63616 says that even in classic skin the 
implementation of editable-menulists has problems on platforms other than 
windows.
I'm glad there's already a bug!
Composer also needs the editable menulist for its Advanced Edit dialog,
so we can replace the "Name" and "Value" textfields with editable menulists
filled with appropriate attribute names and values.
Blocks: 71743
Assignee: hewitt → marlon
Status: ASSIGNED → NEW
Keywords: nsbeta1nsbeta1+
Themes Triage Team Marking nsbeta1+, sending to Marlon for images, when images 
added to bug then send back to Joe.
*** Bug 74797 has been marked as a duplicate of this bug. ***
Moving to 0.9.1
Severity: blocker → major
Priority: P1 → P2
Target Milestone: mozilla0.9 → mozilla0.9.1
I sure hope this does get implemented for 6.5! We are spending a lot of time
on the new Advanced Edit dialog (bug 71743), which needs this widget.
Thanks.
No worries, it's not forgotten, just moved.  I have every intention to get this 
new widget in, when ALL the new widgets go in for Modern Mojo. Count on it
cmanske, if you are relying on editable menulists working well, then you should 
be following bug 64325 as well.
Blocks: 75812
*** Bug 76653 has been marked as a duplicate of this bug. ***
It certainly seems like it's time to give up on this bug.  This is a new feature
that really should have been cut off a while ago.  If you really think this
deserves an exception for beta, please put an explanation in this bug for the
PDT to review.  Thanks,  Steve
If you give up on this bug, then you need to give up on wallet as well.  As 
things stand now, the wallet dialog (screens that allow the user to edit/view 
his saved wallet data) works in classic skin only.
Perhaps you could change the XUL? The Mac as a whole has survivied without 
editable menulists since 1984.  :)
Umm, we were promised this for editor, and it is working fine for Windows.
Is it not working on all platforms?
Simon is right, the mac doesn't have a notion of an editable menulist, so there's 
been lotsa discussion over how this should look, so to not confuse either 
platform. Our current idea is to use a text field entry box immediately adjacent 
to a widget button with a black, down arrow inside:

 ------------------------  ---
| Edit Text Field        || V |
 ------------------------  ---


or, just the black down arrow (without button):


 ------------------------  
| Edit Text Field        |  V 
 ------------------------


i've seen something close to the latter on mac before



oops this bug has been fixed by Joe Hewitt
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Since this bug occurs in Classic theme only, I will verify later because the 
classic theme is broken on all platforms with today's build though.
Unable to verify this bug because of the bug 83724.
83724 was dupped to bug 82655, so see that one for fixes. (Will be checked in
for 0.9.2)
Charles, since someone marked bug 83724 was dupped to bug 82655. And the bug
82655 was marked as "fixed-resolve" which meant that bug 83724 should be fixed.
However, I just verified the bug 83724 on Linux and Mac (branch build:
2001-06-07-11-0.9.1), the bug is still there, not fixed yet. Therefore, 
unable to check this bug 62722 yet because of bug 83724. Thanks!

I think I can clear up the confusion.  The bug that is still not fixed (and 
therefore the one that is blocking the testing on this one) is bug 85300.
Depends on: 85300
I've verified this bug on windows and Linux (commercial build:
2001-06-19-14-trunk), not fixed yet. If I remember correctly, last time
it worked fine on Mac, but now it seems broken.

For windows: On modern theme, select Tasks > Privacy and Security > Form Manager
> Primary Contact Information > Name, Address, Phone number, Credit card, et...
it works fine but "Shipping Information or Billing Information" is broken on
that part.

For Mac and Linux: On modern theme, select Tasks > Privacy and Security > Form 
Manager > Primary Contact Information > Name, Address--can not type any
text at all. Reopen
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Milestone reality check.
Target Milestone: mozilla0.9.1 → mozilla0.9.4
reassigning to default
Assignee: marlon → hewitt
Status: REOPENED → NEW
I believe this can be marked "fixed" now.
fixed indeed.
Status: NEW → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
Verified on windows 98 (2001-08-27-06-trunk).
Status: RESOLVED → VERIFIED
*** Bug 15754 has been marked as a duplicate of this bug. ***
*** Bug 119298 has been marked as a duplicate of this bug. ***
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.