Closed Bug 15480 Opened 25 years ago Closed 25 years ago

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

Categories

(Core :: XUL, defect, P3)

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: hangas, Assigned: shaver)

Details

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.
Assignee: saari → shaver
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
Closed: 25 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
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.
Resolution: FIXED → ---
Clearing Fixed resolution due to reopen of this bug.
Target Milestone: M11 → M12
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.
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".
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
Closed: 25 years ago25 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.
Status: RESOLVED → VERIFIED
v
You need to log in before you can comment on or make changes to this bug.