Open Bug 26353 Opened 25 years ago Updated 7 years ago

Can't turn chrome back on in chromeless window


(SeaMonkey :: UI Design, enhancement)

Not set


(Not tracked)


(Reporter: mnimbus, Unassigned)


(Depends on 3 open bugs, Blocks 1 open bug)


(Keywords: access)


(1 file)

One thing that I've found terribly annoying are the javascript windows that pop
up with buttons, address bar, file menu, etc all turned off when I click on a
link.  Most of the time I don't mind having the dumbed down window, but when I
click on a link that takes me to a page with links where I'm likely to do more
browsing and I do not have any buttons I would like to be able to toggle the
buttons back on.

An example, from you can perform reverse phone number
lookups.  When you hit the Search Now button to look up a phone number, it opens
a page with the person's name and address.  The page has links to look up maps
to the address, links to dial the number via some Voice over IP site, and dozens
of other links to various sites.  The problem is that they have disabled the
buttons, status bar, menu, and everything else that's useful while browsing.

Basically, it would be nice to have a menu item to toggle everything that can be
set off or on in the javascript command.
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 (

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
QA Contact: elig → mpt
Nope whether or not to show the toolbar is at the discretion of the author of the 
page using the standard javascript call I believe this 
implemented exactly as intended. Navigation is available through the context 
Marking invalid.
Closed: 24 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

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.
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'
to ben...
Assignee: german → ben
-> nobody, helpwanted. 
Assignee: ben → nobody
Keywords: helpwanted
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, 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
Depends on: 75157, 75158
Summary: Allow showing of browser chrome in chromeless window → Can't turn chrome back on in chromeless window
Depends on: 45950
No longer depends on: 75157
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.

- 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
-> me
Assignee: blake → ben
javascript:"a b c a b a b a c".replace(/a /g,"")=="b c b b c"
please use that assuming it's useful instead of while (1) { 
drive(Timeless,somewhereBad(tm)) }
+    // Show the menu bar if it is hidden. 
+    showMenubar : function () {
+      var windowElement = document.documentElement;
+      var chromeHidden = windowElement.getAttribute( "chromehidden" );
+      while ( 1 ) {
+        var menubarIdx = chromeHidden.indexOf("menubar");
+        if ( menubarIdx != -1 )
+          chromeHidden = chromeHidden.substring(0, menubarIdx) + 
chromeHidden.substring(menubarIdx + "menubar".length, chromeHidden.length);
+        else break;
+      }
+      windowElement.setAttribute("chromehidden", chromeHidden);
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.
Keywords: access
Blocks: 86758
I think that the menu gets hidden differently:
Is there a JavaScript interface to ShowMenuBar?

Once you have the menubar, and once bug 75742 has been fixed properly,
you will be able to show the status and toolbars.
However that still leaves the URL bar and the scrollbars.
nav triage team:

Not super critical for 0.9.4, pushing out to 0.9.5
Target Milestone: mozilla0.9.4 → mozilla0.9.5
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. 
Target Milestone: mozilla0.9.6 → Future
Depends on: 69099, 81331
*** 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

*** 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
Blocks: uaag
*** Bug 151991 has been marked as a duplicate of this bug. ***
The following window features may be accessed (and altered by chrome) from
JavaScript even after the window has opened: menubar, toolbar, locationbar,
personalbar == directories, statusbar, scrollbars.
As far as I can tell, the scrollbars.visible property only affects subsequent
documents loaded (or reloaded) into the particular frame. Since this will be a
content frame the usual replacable property caveats apply.
Other bars may be enabled using any window or frame e.g. menubar.visible =
false; or window['menubar'].visible = true; (try it in the JS console on the Mac :-)

Of course, this doesn't take into account any View / Show/Hide settings.
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. ***
Bug 75158 is closely related to this bug.
Bug 176304 is for Phoenix. 

I agree entirely and unconditionally with comment #5 of this bug.


>The following window features may be accessed (and altered by chrome) from
JavaScript even after the window has opened: menubar, toolbar, locationbar,
personalbar == directories, statusbar, scrollbars.

These toolbars are (or rather should be - see bug 55820 and bug 155660)
accessible and are _only_ settable if the user grants security privileges.


I really wish this bug (and many other co-related/similar bugs) would be fixed
once for all so that this whole chrome UI elements and normal standard browser
functionalities issue and matter would be clarified and clear for every Mozilla

In comment #10, Matthew mentioned Internet Explorer 5.0 for Mac OS was giving
full control to the user. I think it is now safe to say that Opera 7 (from 7.0
beta 1 to 7.01) gives full control to users as well. The only windowFeature
scripters can decisively affect is the presence (or not) of a locationbar in the
popup window and that it's. In part due to its pure MDI interface, the titlebar,
menubar, navigation toolbar, personalbar, page bar, statusbar, scrollbars,
window resizability, system icons (minimize, restore/maximize, close), system
menu (restore, move, size, etc..) cannot be removed nor crippled via javascript
in Opera 7.x.
Blocks: useragent
Sigh.... It's been over THREE years, and this issue cannot be resolved yet!
The great news is that I have tabbrowser extension installed today, and with
"Open tabs instead of windows for" "New windows opened by Javascript", web designer
can no longer take my menu bar away! There are much more features provided,
people suffer from chromeless windows like me should go try it.
BTW, I am so glad that UI team won't like this kind of context menu monster! :>
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!
Keywords: helpwanted
Priority: P3 → P4
Target Milestone: Future → mozilla1.9beta
Product: Core → Mozilla Application Suite
*** 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 

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. ***
Target Milestone: mozilla1.9beta → ---
*** 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
Priority: P4 → --
QA Contact: bugzilla → guifeatures
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.