Moving all UE/UI bugs to new component: User Interface: Design Feedback UE/UI component will be deleted.
Component: UE/UI → User Interface: Design Feedback
reassign it to german to take a look though I don't think we will be able to do it this version.
Assignee: shuang → german
Summary: Request for menu or right click menu items to toggle file menu, buttons, address bar, etc → Request Feature: menu or right click menu items to toggle file menu, buttons, address bar, etc
QA Assigning non-confidential New/Assigned User Interface: Design Feedback bugs to Matthew Thomas (firstname.lastname@example.org). Matthew Thomas is now the QA owner for the User Interface: Design Feedback component. (Bugs that involve UI issues in the Netscape-branded Mozilla browser should continue be QA assigned to email@example.com.)
QA Contact: elig → mpt
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → INVALID
Part of the philosophy of Mozilla is to behave in an acceptable fashion with all sorts of badly-authored stuff that gets thrown at it. Examples: * quirks mode, for coping with bad HTML * style sheet UI, for overriding bad author CSS * removing corrupt References: msg-ids on reply, for coping with bad Usenet messages. This is the same thing. If a Web author errantly uses a chromeless window for browsing purposes, the user should have the ability to override that by showing the chrome. Just providing navigation in the context menu is not enough -- as that would still prohibit me from saving, printing, copying the URL, sending the document, editing the document, finding text in the document, loading all images, changing the text encoding ... A document author should not have absolute sovereignty over what I can and can't do with the document. Reopening and resummarizing.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Summary: Request Feature: menu or right click menu items to toggle file menu, buttons, address bar, etc → Allow showing of browser chrome in chromeless window
OK I see your point Mat, although I am not sure I agree. I propose reassigning this bug to ben, the mozilla UI owner, so he can add this to his 'ongoing discussions bin'
Assignee: german → ben
Status: REOPENED → NEW
-> nobody, helpwanted.
Assignee: ben → nobody
Chaning the qa contact on these bugs to me. MPT will be moving to the owner of this component shortly. I would like to thank him for all his hard work as he moves roles in mozilla.org...Yada, Yada, Yada...
QA Contact: mpt → zach
Reassigning nobodied UI:DF bugs to me ... Internet Explorer 5.0 for Mac OS leaves all the menus available, so it's trivial to turn the toolbars etc on again when a Web site has opened a window with them turned off.
Assignee: nobody → mpt
I'd like a way to do this on WinNT. I believe IE4 overloaded the application menu (the menu from the application icon on the titlebar that normally has just move/size/min/max/close options) to have additional items so you could show the toolbar / statusbar / menus when you didn't have them.
From bug 70830 - one of the probably numerous situations that a user can end up in with a chromeless window and poorly developed content: Brief Directions to fixing 26353: add a "Show Menu Bar" menu item to the context menu XUL. Set hidden="true" on it. when displaying a context menu: - obtain the <window> node of navigator.xul - obtain the |chromehidden| attribute - check for the presence of the string "menubar" within that attribute value. If so, remove the hidden attribute on the menu item. the handler for "Show Menu Bar" is as follows: - obtain the |chromehidden| attribute on the <window> element. - use string functions to remove the "menubar" segment. - set |chromehidden| again with the modified string. This will cause the menubar to appear. Notes: - this solution won't affect other context menu clients as AFAIK only browser uses the chromehidden attribute. As long as the code checks return values etc it should not harm mailnews or the sidebar. I'd prefer to see a patch that implements the solution outlined above or something similar to it.
Target Milestone: --- → mozilla0.9.4
--> XP Apps: GUI
Assignee: mpt → blake
Component: User Interface Design → XP Apps: GUI Features
QA Contact: zach → sairuh
Assignee: blake → ben
From my chat with Ben: For accessibility purposes, here are things the user needs to be able to get to in any window: - menu bar - scroll bars - resizeability - minimize/maximize/close buttons - system menu I believe there should be an option in the conte4xt menu to "open in full browser window" or "change to full browser window" It only needs to show up when there are chrome features disabled. Interestingly, I did find a way to do this with current builds. Change your prefs to "WHen navigator starts up, display" -> "Last page visited". Then when you're in a chromeless window, type Accel+N. Bing, there it is, in a full browser window, menubars, statusbars, everything. BTW, why does Accel+N behavior have to be tied to my app startup page? I'd like Accel+N to always open the current page in a new window.
nav triage team: Not super critical for 0.9.4, pushing out to 0.9.5
Target Milestone: mozilla0.9.4 → mozilla0.9.5
RFE, -> 0.9.6
Mass-moving lower-priority 0.9.5 bugs off to 0.9.6 to make way for remaining 0.9.4/eMojo bugs, and MachV planning, performance and feature work. If you disagree with any of these targets, please let me know.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
OK This is a little more complicated than I thought. Having to shift out again due to other priorities.
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.6 → Future
*** Bug 112965 has been marked as a duplicate of this bug. ***
"This is a little more complicated than I thought." Ben, what exactly is the problem? I have a working testversion of MultiZilla where we have added a single menu item to the tab menu. We called it "Enable Menu and Toolbars". We simply remove the chromehidden attribute, and that seems to enable the menu and toolbars. The only thing I need to know is, how I should enable the resize and scrollbars functions, if this is disabled with scrollbars=0/resize=0 in window.open() -Neil.
*** Bug 127279 has been marked as a duplicate of this bug. ***
*** Bug 122532 has been marked as a duplicate of this bug. ***
*** Bug 70830 has been marked as a duplicate of this bug. ***
Not much appears to have been going on since last fall. As would be pretty obvious from what people wrote in bug 70830, taking care of this bug (to solve the problem raised in bug 70830 as well as other problems) would, I believe, make a lot of Mozilla users (who need to view non-US-ASCII pages very often among other things) a lot happier :-) or prevent them from turning to MS IE (I have to resort to MS IE frequently because I can't change the encoding, print the page, take the URL, etc in a chromless window) Therefore, I thought it might not be so bad to spur a little more activities here by writing this comment.
*** Bug 117417 has been marked as a duplicate of this bug. ***
Need to look at this with UI team.
Assignee: ben → aaronl
Status: ASSIGNED → NEW
*** Bug 151991 has been marked as a duplicate of this bug. ***
Another aspect of this is that Mozilla has tabs. If a web site opens a window with no toolbars and I then "open link in new tab" a link off that page, it will also be necessarily missing the toolbars, even though it may be an external link from that site and never intended to be that way even by its author. It seems quite inconsistent that it's sometimes necessary to "open link in new window" just to get toolbars, when the user would prefer to do "open link in new tab" and turn toolbars on.
*** Bug 188526 has been marked as a duplicate of this bug. ***
Sorry I can't be more helpful, but this is clearly a good example of something that needs action, that is assumiong it really is still open. User control is paramount. hope this gets solved soon!
Status: NEW → ASSIGNED
Priority: P3 → P4
Target Milestone: Future → mozilla1.9beta
*** Bug 279397 has been marked as a duplicate of this bug. ***
(In reply to comment #38) > *** Bug 279397 has been marked as a duplicate of this bug. *** I think I now understand why this bug has not been fixed. in the bug I posted's comments I see >> Actual Results: >> the popup with no tollbar turns blank and there is no apparent way to close it. > >Yes, there is: Ctrl+W on Windows platform and Cmd+W on MacOSX The operative word here is "apparent." there is nothing to indicate that there is a way out of this problem. You just have to know. On OS X, [command]-W implies close the window, a big thing to ask for when you have a long email in that other tab. plus, how do you know that it is even a new tab that opened? So it seems that the fact that there is a workaround for poeple who are quite savvy with their computer means that the bug does not need to be fixed. This, I guess, stems from the belife that Mozilla is a programers browser and not a general purpose browser? correct me if I'm wrong...
Another interesting consequence of this bug is that in a chromeless window, if the user hits Accel-T (by accident perhaps), they might get really confused -- where's their page gone? There's just a blank! Related to this bug: chromeless windows still show the toolbar itms in the view menu as ticked, even though they are not visible.
*** Bug 283447 has been marked as a duplicate of this bug. ***
*** Bug 138615 has been marked as a duplicate of this bug. ***
*** Bug 294339 has been marked as a duplicate of this bug. ***
Assignee: aaronleventhal → nobody
Status: ASSIGNED → NEW
Priority: P4 → --
QA Contact: bugzilla → guifeatures
You need to log in before you can comment on or make changes to this bug.