Closed Bug 53322 Opened 24 years ago Closed 24 years ago

Possible to put toolbars into unrecoverable state

Categories

(Core :: XBL, defect, P1)

Product:
Core
Component:
XBL
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: hyatt, Assigned: dr)

Details

(Whiteboard: [nsbeta3-][rtm need info])

In the modern skin, if the primary toolbar is collapsed, you end up in an unrecoverable state. The toolbar becomes unexpandable, and you can never get it back (unless you switch to Classic). This is because async XBL doesn't guarantee a bindingattached event firing order for parents and children. It should, and this is the cause of the bug.
Nominating for nsbeta3.
Status: NEW → ASSIGNED
Keywords: nsbeta3
Thanks to the modern skin's collapsible menubar, this bug has a worst-case scenario where you basically can't use the product at all, with only obscure workarounds (switch skins, open a second window using component bar). Hard to fix correctly, but should be able to put in a temporary fix. nsbeta3+/p2
Priority: P3 → P2
Whiteboard: [nsbeta3+]
Target Milestone: --- → M18
"view | toolbars | navigation toolbar" isn't able to turn it back on?
Priority: P2 → P1
Whiteboard: [nsbeta3+] → [nsbeta3+][need info]
PDT: Holding for resolution of Selmer's question. Need info on workarounds.
No, it isn't. The View menu does a show/hide. This is a collapsed/uncollapsed bug.
The workarounds that I know of: switch skins or open a new window. I have a way to fix this bug that doesn't involve a full-scale bindingattached fix. I can just hack the XUL/JS to make sure this works. It's safe and pretty trivial to do if I go that route.
mass-adding rtm keyword to all open nsbeta3+ xptoolkit bugs
Keywords: rtm
marking rtm+, would like to quick fix by moving a helper method. very safe.
Whiteboard: [nsbeta3+][need info] → [nsbeta3+][rtm+]
nsbeta3-
Whiteboard: [nsbeta3+][rtm+] → [nsbeta3-][rtm+]
PDT marking [rtm need info] until code reviews are available.
Whiteboard: [nsbeta3-][rtm+] → [nsbeta3-][rtm need info]
->dr
Assignee: hyatt → dr
Status: ASSIGNED → NEW
this works for me in the branch tip on win2k (as well as linux and mac)... hyatt: is this still occurring for you? is this an nt4-only bug?
Status: NEW → ASSIGNED
resolving as wfm
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.