If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

[PP] Windows menus do not grow to allow for dynamically changed text

VERIFIED FIXED in M12

Status

()

Core
XUL
P3
normal
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: hangas, Assigned: shaver)

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
When the text of a menu item is changed the size of the menu does not grow to
allow for the new text.  I set a menu item to be longer than any other text in
that menu and the menu 'window' did not increase in size so the new menu item had
the first three letters of the text followed by "...".  The menu 'window' needs
to be resize to accomodate the new menu item length.  This works fine on the Mac.

Updated

18 years ago
Assignee: saari → shaver

Comment 1

18 years ago
shaver wrote this code... shaver, make sure a reflow is happening when the
"value" attribute changes on the titledbutton.
Status: NEW → ASSIGNED
Target Milestone: M11
I think I have a fix for this (need to reflow the menuframe, not just the
titledbutton, duh); can you throw a test case at me so I can be sure?
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Reporter)

Updated

18 years ago
Status: RESOLVED → REOPENED
(Reporter)

Comment 3

18 years ago
Reopen bug since it is still happening.  For a test case, go to the address book,
select an address book and then look at the edit menu's "Delete" menu item.  It
should have changed to "Delete Address Book" instead it says "Delete Ab..."
because the menu did not resize.  You need a current tree as of 6:30pm 11/4/99 to
see the text change on Windows.

Updated

18 years ago
Resolution: FIXED → ---

Comment 4

18 years ago
Clearing Fixed resolution due to reopen of this bug.

Updated

18 years ago
Target Milestone: M11 → M12

Comment 5

18 years ago
think we need to deal with this after m11
Hello...anyone out there?

I'm still waiting for a minimal test case so I can diagnose this.  Hurry and we
can still get a fix in the M11 builds.
(Reporter)

Comment 7

18 years ago
TEST CASE: Use the test case I gave on 11/4/99 (go to the address book, select an

address book), but because of a new focus issue, open the Edit menu with ALT-E to

see that "Delete Address Book" is displayed as "Dele...".  The Alt-E is needed

because in current builds clicking on the Edit menu changes the focus to the menu

which changes the text of the menu back to "Delete".

Comment 8

18 years ago
Here is a small xul test case (click the menu item repeatedly):

<?xml version="1.0"?>
<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>

<window
  xmlns:html="http://www.w3.org/TR/REC-html40"
  xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
  align="vertical">

  <html:script>
  function cmdClick() {
    var item = top.document.getElementById("miClickMe");
    var value = item.getAttribute("value");
    if (value == "Click Me")
      item.setAttribute("value", "Please Try Again");
    else
      item.setAttribute("value", "Click Me");
  }
  </html:script>

  <menubar>
    <menu accesskey="M" value="Menu">
      <menupopup>
        <menuitem value="Click Me" id="miClickMe" oncommand="cmdClick();"/>
      </menupopup>
    </menu>
  </menubar>
</window>
OK, I can't reproduce this on Linux: the menu item is always long enough for
both options, but if I make the text really really really long, it reflows
correctly.  Can someone verify that this is _still_ happening, before I try to
get a Windows machine to build for me?

Thanks
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED
I just had someone test this on Windows (1999112908 build) and they say it works
correctly too.  Time kills bugs dead.

Updated

18 years ago
Status: RESOLVED → VERIFIED

Comment 11

18 years ago
v
You need to log in before you can comment on or make changes to this bug.