Open Bug 75158 Opened 23 years ago Updated 2 months ago

`View' > `Show/Hide' menu items can't override window.open flags

Categories

(Core :: DOM: Core & HTML, defect, P5)

defect

Tracking

()

Future

People

(Reporter: mpt, Unassigned)

References

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

Details

(Whiteboard: [p-ie/mac])

Attachments

(1 file, 2 obsolete files)

Build: 2001040408, Mac OS 9.1.

To reproduce:
*   Open a Navigator window, and go to <http://numberfinder.com/>.
*   Perform a search for anything.
*   In the window which comes up, use the `View' > `Toolbars' submenu to turn
    the toolbars back on.

What should happen:
*   The items in the `View' > `Toolbars' menu should be unchecked, and checking
    them should turn the toolbars back on.

What actually happens:
*   The items in the `View' > `Toolbars' menu are checked, and unchecking them
    and re-checking them has no effect.
Blocks: 26353
The window that comes up for me doesn't have a menu bar, so I can't use the 
View menu to re-show the toolbar.

Gerv
Doh! Of course. I see. MacOS. Yes. Right.

Gerv
That means pchen, I think.
OS: other → Mac System 9.x
Hardware: Other → Macintosh
C, d'you see this?
QA Contact: sairuh → claudius
yup, in 2001041008 builds, but I wasn't really surprised. Isn't this exactly what the author intended?
It wouldn't even be possible on another platform. Maybe the 'toolbar' item should just be greyed out?

regardless, reassigning to appropriate people.
Assignee: ben → pinkerton
Component: XP Apps: GUI Features → XP Toolkit/Widgets: Menus
QA Contact: claudius → jrgm
-> pchen
Assignee: pinkerton → pchen
Component: XP Toolkit/Widgets: Menus → XP Apps: GUI Features
I don't see what purpose disabling the items would serve, other than annoying 
people. The author got what he/she asked for -- a window without chrome. Now 
when I decide to turn the chrome on again (because it's *my* Web browser, not 
the Web author's), the toolbar items don't do anything. I can turn the toolbars 
back on in Internet Explorer, why not in Mozilla?
Whiteboard: [parity-ie/mac]
-> me, if Paul doesn't mind...
Assignee: pchen → blakeross
Sorry, I didn't realize this was Mac-only when I took it (I think I have 
another bug somewhere on these items not working on other platforms when the 
popup has a menubar).  Back to Paul, but e-mail me if you're willing to send me 
a mac and I'll respond with my address.
Assignee: blakeross → pchen
Priority: -- → P1
Target Milestone: --- → mozilla0.9.1
Keywords: nsbeta1-
Target Milestone: mozilla0.9.1 → Future
I have reproduced problem. Click on side tab to "close" the tab, then go to View
-> Toolbar and uncheck the item.  It won't come back or show. Happens in Mail as
well as browser. 
Blocks: 103711
->default assignee
Assignee: pchen → blaker
QA Contact: jrgm → sairuh
Target Milestone: Future → ---
->XP Apps default assignee
Assignee: blaker → trudelle
Component: XP Apps: GUI Features → XP Apps
sorry, this was supposed to be XPApps: GUI Features
Assignee: trudelle → blaker
Component: XP Apps → XP Apps: GUI Features
Target Milestone: --- → Future
Also broken on Windows:
javascript:window.open("", "", "menubar=yes"); void 0
OS: Mac System 9.x → All
Hardware: Macintosh → All
*** Bug 75742 has been marked as a duplicate of this bug. ***
Summary: `View' > `Toolbars' items don't work in chromeless window → `View' > `Show/Hide' menu items can't override window.open flags
Whiteboard: [parity-ie/mac] → [p-ie/mac]
Scraps:

1. 
<http://lxr.mozilla.org/mozilla/source/xpfe/browser/resources/content/navigator.js#1652>
2. 
<http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/navigatorOverlay.xul#167>
3.  var chromehidden=document.documentElement.getAttribute("chromehidden");
    var morechrome=chromehidden.replace(/\btoolbar\b/g," ");
    if (chromehidden!=morechrome) 
        document.documentElement.setAttribute("chromehidden",morechrome)
    else
        do the usual thing
    endif
taking... i got some lines from timeless which i converted into a real fix *eg*,
i will attach it as soon as my cygwin setup is finished... (or tomorrow,
whichever one comes first)
Assignee: blaker → rossi
Attached patch Proposed patch (obsolete) — Splinter Review
Note that this patch does not do anything about the checkmarks on the menu
because they are persisted so changing them to reflect the window.open flags
would impact on new windows. Nor does this patch fix the sidebar.
Attached patch Updated patchSplinter Review
Attachment #84058 - Attachment is obsolete: true
Comment on attachment 84631 [details] [diff] [review]
Updated patch

I have talked to jst about this a while ago.  We don't want to fix it this way,
since it will not update the window flags it needs to.	There is going to be
some c++ stuff that I'll code up hopefully sometime soon that will take care of
this and some other problems with window features as well.
Attachment #84631 - Flags: needs-work+
I've been looking for a placeholder for some of this stuff.  This bug will do
just nicely.
Assignee: rossi → caillon
Component: XP Apps: GUI Features → DOM Level 0
Depends on: 55820, 155660
Keywords: patch, polish, review, ui
Priority: P1 → P3
QA Contact: sairuh → desale
Assignee: caillon → general
QA Contact: desale → ian
Blocks: 244412
*** Bug 251329 has been marked as a duplicate of this bug. ***
No longer blocks: 244412
*** Bug 244412 has been marked as a duplicate of this bug. ***
Assignee: general → nobody
QA Contact: ian → general
Bulk priority change, per :mdaly
Priority: P3 → P5

Mass-removing myself from cc; search for 12b9dfe4-ece3-40dc-8d23-60e179f64ac1 or any reasonable part thereof, to mass-delete these notifications (and sorry!)

Severity: normal → S3
Attachment #9384198 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: