133718 - show/hide menu options should never be disabled

Status: RESOLVED FIXED

(SeaMonkey :: UI Design, defect)

Description

[Joseph Delaney]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.9+)
Gecko/20020322
BuildID:    2002032203

When a javascript creates a new window with no toolbars showing, the menus to
show the Navigation Toolbar or the Personal Toolbar do nothing (usually).
Sometimes a check mark shows up in the menu, but the toolbar never appears in
the new window.

This could be used to redirect someone to  a different site and prevent them
from knowing where they are since they cannot see the URL. Very, very bad, if
you are concerned with security at all. 

Reproducible: Always
Steps to Reproduce:
1. Go to any page that uses creates a new window with the toolbars hidden (like
http://www.netscape.com/ does the first time you visit it that day).
2. When the new window appears, click on the "View" menu, then  "Show/Hide" and
"Navigation Toolbar".


Actual Results:  Nothing happens, or sometimes a checkmark appears next to the
"Navigation Toolbar" menu item, but the toolbar itself never appears.

Expected Results:  The toolbar should appear when requested.

I've tried this on many sites, and with both the classic and modern themes on
Mac OS X. Mozilla has behaved like this for a while, not just with this build.
I'll try it with a Windows build later today.

Comment 1

[Joseph Delaney]

Attachment: Link to open a new window with a menubar, no toolbars

I couldn't tell if this affected Windows builds for the simple fact that
Windows keeps it's menubar in the window itself, not permanently at the top of
the screen. Clicking the link in this attachment will open a new window with
the menu bar showing, so you can then try to view the toolbars.

But I'm not a PC today, probably won't be for 3 days or so (oh, bliss!) and
still can't test it.

Comment 2

[Paul Wyskoczka]

qa --> [e-mail]

Comment 3

[Greg K.]

Confirmed using FizzillaCFM/2002041712 (RC1).

Comment 4

[Samir Gehani]

-> Blake for menus.  Maybe we need to disable items that aren't working.  Or fix
them so they do what they advertise.

Comment 5

[Frankie]

1 year later... still a problem in Moz 20030312 OSX.

Comment 6

[Joseph Delaney]

Well, they can't fix everything at once ;-) I'm glad they devoted the time to
fix the random gray screens rather than fixing this one, and now I hope they fix
the XPInstall problems. 

But as for Comment #4, please do not disable the menu. As far as I am concered,
you should never never never block the user from seeing the URL bar if they want
to, so please do not disable.

I have tried my test case on a PC running Windows XP and Mozilla 1.3, it also
fails to show the Navigation Toolbar when choosing it from the menu. 

Comment 7

[Asa Dotzler [:asa]]

The real solution is to disable those menu items since the window was
explicitely created without toolbars. If you want the ability to block sites
from creating windows without toolbars, that's bug 196327. You can do it now by
going to about:config and typing dom.disable_window_open in the filter field.
That will give you a list of preferences that you can set to "true" to block
sites from disabling the various UI elements

Re-summarizing the actual bug here from "Can't show Navigation Toolbar in pop-up
windows" to "windows created toolbars should have the show/hide option for those
toolbars disabled."

*** This bug has been marked as a duplicate of 196327 ***

Comment 8

[Asa Dotzler [:asa]]

oops, didn't mean to dupe this. reopening.

Comment 9

[R.K.Aa.]

dup of bug 69099?

Comment 10

[Joseph Delaney]

If you look at this the way it was originally filed, it is very similar to bug
69099 but not quite the same. That bug discusses an enhancement to add a menus
or some other method (fkey, etc) for bringing back toolbars, I opened this bug
as a complaint that already-existing menus did not work.

And then Asa changed the summary so it is not a dupe at all, but I disagree with
the new summary.  

The ability to block the hiding of toolbars is a welcome addition, and I've
enabled those preferences, but for the user who has not done that prior to
clicking a link where some idiot has hidden the url bar or the scrollbars or
what have you, the only option left is to close the window, go into the prefs
and change settings, then go back to click the link again. Not exactly
user-friendly.

Moreover, the preference is an all-or-nothing setting. Sometimes very smart
people hide the url bar or the scroll bars or what have you for very good
reasons. Most of the time I want to honor the choices of the web designer, but
when the idiots do it I want to view those toolbars again to see where that link
has really taken me, or scroll a window that they obviously did not look at on a
Mac, or had no idea what that checkbox in Dreamweaver did, etc. That only
happens sometimes so the permanent, all-or-nothing preference does not really
work for me. 

So this bug should really be about making the existing menus do what they say,
not about disabling them. Bug 69099 could probably be made to fit this one if it
is noted there that the menus already exist on the Mac and that they can be made
to exist on windows as is done in the attachment.  

Comment 11

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 12

[Joseph Delaney]

This bug still applies to Seamonkey 1.1.16 (Mac) and it is still a phishing problem.

You can see it happen by clicking the file that is attached to this bug, and then trying to re-enable the navigation toolbar (the user cannot turn the URL bar back on, and is effectively blocked from seeing or confirming the address of the web site  they are looking at).

Furthermore, this has been partly addressed (somewhat) in Firefox 3.5 by Bug 133718 which fixes the phishing aspect (without the phishing, this is a much less important interface annoyance). It's also fixed in Camino (and Safari) which allows the URL bar to be hidden, but also allows the user to show it again.

Comment 13

[therube]

By default, various SeaMonkey Show/Hide menu options can be hidden.
By setting Preferences, that can be overridden.

If the intent is to prevent various Show/Hide menu options from being disabled (from a JavaScript opened window), then said Preferences can be defaulted to True.  (FF 4 - FF 6 do this.)

As it is, default actions differ between SeaMonkey 2.1 vs FF 4 - FF 6.

Suppose the biggest nit here is: dom.disable_window_open_feature.location


Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20110511 Firefox/4.0.1 SeaMonkey/2.1

Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

Mozilla/5.0 (Windows NT 5.1; rv:6.0a1) Gecko/20110519 Firefox/6.0a1


Note the related bugs mentioned above.

Comment 14

[Phoenix]

Still here, to reproduce use attachment from Comment 1
Build identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111017 Firefox/10.0a1 SeaMonkey/2.7a1

Comment 15

[u597032]

Fixed now