Can't turn chrome back on in chromeless window

NEW
Unassigned

Status

SeaMonkey
UI Design
--
enhancement
18 years ago
a year ago

People

(Reporter: kevin arnold, Unassigned)

Tracking

(Depends on: 3 bugs, Blocks: 2 bugs, {access})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
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

18 years ago
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

Comment 2

18 years ago
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

Comment 3

18 years ago
QA Assigning non-confidential New/Assigned User Interface: Design Feedback bugs 
to Matthew Thomas (mpt@mailandnews.com).

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 elig@netscape.com.)
QA Contact: elig → mpt

Comment 4

17 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID

Comment 5

17 years ago
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

Comment 6

17 years ago
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

17 years ago
to ben...
Assignee: german → ben
Status: REOPENED → NEW
-> nobody, helpwanted. 
Assignee: ben → nobody
Keywords: helpwanted

Comment 9

17 years ago
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

Comment 10

17 years ago
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

Updated

17 years ago
Depends on: 75157, 75158
Summary: Allow showing of browser chrome in chromeless window → Can't turn chrome back on in chromeless window

Updated

17 years ago
Depends on: 45950

Updated

17 years ago
No longer depends on: 75157

Comment 11

16 years ago
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

Comment 13

16 years ago
--> XP Apps: GUI
Assignee: mpt → blake
Component: User Interface Design → XP Apps: GUI Features
QA Contact: zach → sairuh
Created attachment 43511 [details] [diff] [review]
patch to implement "Show Menu Bar" item
-> me
Assignee: blake → ben

Comment 16

16 years ago
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

16 years ago
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

Updated

16 years ago
Blocks: 86758

Comment 18

16 years ago
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

16 years ago
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

Comment 21

16 years ago
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

Updated

16 years ago
Depends on: 69099, 81331

Comment 23

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

Comment 24

16 years ago
"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

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

Comment 26

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

Comment 27

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

Comment 28

16 years ago
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

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

Comment 30

15 years ago
Need to look at this with UI team.
Assignee: ben → aaronl
Blocks: 24413
Status: ASSIGNED → NEW

Comment 31

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

Comment 32

15 years ago
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

15 years ago
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

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

Comment 35

15 years ago
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.
Blocks: 86194

Comment 36

14 years ago
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

13 years ago
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!

Updated

13 years ago
Status: NEW → ASSIGNED
Keywords: helpwanted
Priority: P3 → P4
Target Milestone: Future → mozilla1.9beta
Product: Core → Mozilla Application Suite

Comment 38

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

Comment 39

13 years ago
(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

13 years ago
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

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

Updated

13 years ago
Target Milestone: mozilla1.9beta → ---

Comment 42

13 years ago
*** Bug 138615 has been marked as a duplicate of this bug. ***
*** Bug 294339 has been marked as a duplicate of this bug. ***

Updated

10 years ago
Duplicate of this bug: 366013
Assignee: aaronleventhal → nobody
Status: ASSIGNED → NEW
Priority: P4 → --
QA Contact: bugzilla → guifeatures

Updated

9 years ago
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.