Closed Bug 8689 Opened 26 years ago Closed 26 years ago

[RFE] Means of reloading Navigator.XUL required

Categories

(Core :: XUL, enhancement, P2)

Product:
Core
Component:
XUL
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: Crysgem, Assigned: hyatt)

Details

In the Lose98 1999061908 Apprunner build, at the least, there is no means of reloading Navigator.XUL during a session. (I presume this lack applies to all platforms)
In response to hyatt@netscape.com's comment dans le newsgroup, stating that the opening of a new window would acheive this function - such smacks of a workaround. Will not this function (clearly identified) be required as our brave open world approaches the release?
What is the real requirement here, why reload during a session?
Reveal the meridian range of my reasoning at a moment? You are evidently no military strategist. Is it possible to do so, load the XUL? Yes, XUL may be loaded by scripted command. But what of the user standing before the sheer wall of the FE? Attend: Is there sufficient flexibility in the... Aurora specification, yes?... to offer the simple option of choosing among chrome sets? When the possibility of a customizable GUI claps through the user populace, surely a clamoring for a simple menu to select one's chrome will be felt. (Multiple chrome sets may be cached, yes?). I had considered that a simple hardwired node to select Navigator.XUL, to effectively reload it, might be easily injected in this hour as a placeholder for the future chrome selection mechanism... The requirement, my good coder, is the meeting of my simple, selfish desire to hack on Navigator.XUL, with quickly returned results, for mine own education. There are further arguments, but I'm certain you may fire this report down or elevate it by these words alone.
Assignee: trudelle → hyatt
Priority: P3 → P2
Reassigning to hyatt as p2 for M9, assuming that this work is already covered by the downloadable chrome tasks on our schedule.
Status: NEW → ASSIGNED
Target Milestone: M9
This is not something that can be generally allowable from within a content shell without the user's permission and lots of warning, since it would allow anyone to reload the chrome (and that's a bad thing). trudelle is right that the reloading on a skin/content change will be part of the higher-level chrome API slated for M9.
Target Milestone: M9 → M12
My hands have deteriorated to the point where I can no longer type. I need help. If you think you can fix this bug on your own, please take it away from me. If you'd like to volunteer to be my hands for a specific bug, then I'll be happy to come up to your cube and sit with you and fix the bug (assuming you have the patience for that).
Target Milestone: M12 → M14
moving post beta (m14)
spam: changing qa contact from ckritzer -> paulmac for xul bugs
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Done. nsIChromeRegistry::RefreshSkins can be used to flush and reload only style sheets. nsIChromeRegistry::ReloadChrome can be used to reload all chrome windows.
QA Contact: paulmac → Crysgem
Crysgem, please verify, thanks
QA Contact: Crysgem → paulmac
While I would greatly enjoy donning the overshoes necessary for wading through newly crafted code, such is not in step with my reputation for annoying requests. Comrades, perhaps I should have phrased differently: An *interface* point (for the user) is required to reload Navigator.XUL. There is no menu-item presently evident (or buried, so far as I seek) which would perform this task. I doubt not that the mechanism is implemented - however, I cannot confirm this. Should a new bug requesting an interface button or item which would reload the XUL be filed?
hyatt, is there need for a menu item to reload the style sheets and/or chrome?
I do not believe that a menu item like that is required. If you switch skins, navigator.xul doesn't reload. The CSS files are refreshed without reloading the XUL. This happens automatically on a skin switch.
The skin switching UI is in the prefs. It is not functional as yet, but that's where the actual skin switching code will live. As for being able to force a reload of navigator.xul, you need to disable the XUL cache and then just open new windows as you hack on the file. There's no need for a menu item to do a reload other than for testing purposes, though, and since there's a clear workaround there (just open a new window), I don't think we need to worry about it.
BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL. XUL component will be deleted.
Component: XUL → XP Toolkit/Widgets: XUL
spam, qa to jrgm
QA Contact: paulmac → jrgm
[RFE] is deprecated in favor of severity: enhancement. They have the same meaning.
Severity: normal → enhancement
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.