26353 - Can't turn chrome back on in chromeless window

Status: NEW

(SeaMonkey :: UI Design, enhancement)

Description

[kevin arnold]

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 http://NumberFinder.com/ 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 window.open command.

Comment 1

[leger]

Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.

Comment 2

[shuang (gone)]

reassign it to german to take a look though I don't think we will be able to do 
it this version. 

Comment 3

[Eli Goldberg]

QA Assigning non-confidential New/Assigned User Interface: Design Feedback bugs 
to Matthew Thomas ([e-mail]).

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 [e-mail].)

Comment 4

[german]

Nope whether or not to show the toolbar is at the discretion of the author of the 
page using the standard javascript call window.open(attributes). I believe this 
implemented exactly as intended. Navigation is available through the context 
menu.
Marking invalid.

Comment 5

[Matthew T (active 1999-2002)]

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.

Comment 6

[german]

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'

Comment 7

[german]

to ben...

Comment 8

[Ben Goodger (use ben at mozilla dot org for email)]

-> nobody, helpwanted. 

Comment 9

[Zach Lipton [:zach]]

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...

Comment 10

[Matthew T (active 1999-2002)]

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.

Comment 11

[Tim Powell]

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.

Comment 12

[Ben Goodger (use ben at mozilla dot org for email)]

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. 

Comment 13

[Matthew T (active 1999-2002)]

--> XP Apps: GUI

Comment 14

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: patch to implement "Show Menu Bar" item

Comment 15

[Ben Goodger (use ben at mozilla dot org for email)]

-> me

Comment 16

[timeless]

javascript:"a b c a b a b a c".replace(/a /g,"")=="b c b b c"
true
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);

Comment 17

[Aaron Leventhal]

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.

Comment 18

[[e-mail]]

I think that the menu gets hidden differently:
http://lxr.mozilla.org/seamonkey/source/xpfe/appshell/src/nsContentTreeOwner.cpp#570
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.

Comment 19

[Paul Chen]

nav triage team:

Not super critical for 0.9.4, pushing out to 0.9.5

Comment 20

[Ben Goodger (use ben at mozilla dot org for email)]

RFE, -> 0.9.6

Comment 21

[Peter Trudelle]

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.

Comment 22

[Ben Goodger (use ben at mozilla dot org for email)]

OK This is a little more complicated than I thought. Having to shift out again 
due to other priorities. 

Comment 23

[:deanis74]

*** Bug 112965 has been marked as a duplicate of this bug. ***

Comment 24

[Neil Pryde]

"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.

Comment 25

[Jesse Ruderman]

*** Bug 127279 has been marked as a duplicate of this bug. ***

Comment 26

[Matthew T (active 1999-2002)]

*** Bug 122532 has been marked as a duplicate of this bug. ***

Comment 27

[Matthew T (active 1999-2002)]

*** Bug 70830 has been marked as a duplicate of this bug. ***

Comment 28

[Jungshik Shin]

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.

Comment 29

[Vadim Berezniker]

*** Bug 117417 has been marked as a duplicate of this bug. ***

Comment 30

[Aaron Leventhal]

Need to look at this with UI team.

Comment 31

[Daniel Wang]

*** Bug 151991 has been marked as a duplicate of this bug. ***

Comment 32

[[e-mail]]

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.

Comment 33

[Craig]

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.

Comment 34

[R.K.Aa.]

*** Bug 188526 has been marked as a duplicate of this bug. ***

Comment 35

[Gérard Talbot]

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
user. 

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.

Comment 36

[Jeffrey Tang]

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.
http://white.sakura.ne.jp/~piro/xul/_tabextensions.html.en
BTW, I am so glad that UI team won't like this kind of context menu monster! :>

Comment 37

[jonathan chetwynd]

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!

Comment 38

[Gérard Talbot]

*** Bug 279397 has been marked as a duplicate of this bug. ***

Comment 39

[Paul Bailey]

(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...

Comment 40

[Joachim Noreiko]

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.

Comment 41

[Joachim Noreiko]

*** Bug 283447 has been marked as a duplicate of this bug. ***

Comment 42

[Gérard Talbot]

*** Bug 138615 has been marked as a duplicate of this bug. ***

Comment 43

[Matthias Versen [:Matti]]

*** Bug 294339 has been marked as a duplicate of this bug. ***