Closed Bug 75158 Opened 24 years ago Closed 5 months ago

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

Categories

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

defect

Tracking

()

RESOLVED INCOMPLETE
Future

People

(Reporter: mpt, Unassigned)

References

(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
Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: