Closed
Bug 8318
Opened 27 years ago
Closed 27 years ago
pop ups obliterate personal toolbar
Categories
(Core Graveyard :: Tracking, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
M8
People
(Reporter: michaell, Assigned: waterson)
References
()
Details
Go to home.netscape.com or some other site that uses pop-ups. You may need to hit reload a couple of times to get a pop-up to appear. When it does, the personal toolbar in the main window disappears, never to be seen again (view|toolbars does not appear to be hooked up).
Peter, this does indeed happen on Windows although I can't reproduce the problem
on Linux. This isn't really an XPApps issue but more of a Javascript and
"window.open" problem. Is Hyatt still workin on that?
Updated•27 years ago
|
Assignee: trudelle → hyatt
Comment 2•27 years ago
|
||
Sounds like he may need to, reassigning.
Updated•27 years ago
|
Assignee: hyatt → danm
Comment 3•27 years ago
|
||
This probably has something to do with Dan's chrome changes. I'm assuming the
wrong webshell is being targeted (the original one instead of the new popup).
Better test case: executing the JS
window.open("whatever", "new", "toolbar=no")
will cause the problem, while an identical line with toolbar=yes will not.
The "chrome hidden" flag is copied between the open browser windows for the personal toolbar,
which comes from an RDF datasource. The new window.open window is, yes, just another browser
window. I hope this isn't an architectural problem, but I fear it is. More later.
Comment 6•27 years ago
|
||
The personal toolbar should be using a "ref" attribute rather than an "id"
attribute to point to the RDF data. This will solve your problem.
Assignee: danm → waterson
Status: ASSIGNED → NEW
Whiteboard: problem understood. fix not quite there yet.
Amid worries that the attribute causing the DOM node to be hidden is being set
in the wrong datasource, this bug finds a new home in the RDF camp.
| Assignee | ||
Updated•27 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M8
There's a workaround in the code now. While the bug itself isn't yet fixed, you can
at least use the menu to get back the missing toolbar.
| Assignee | ||
Updated•27 years ago
|
Whiteboard: investigating
| Assignee | ||
Updated•27 years ago
|
Whiteboard: investigating → fix ready to go
| Assignee | ||
Comment 10•27 years ago
|
||
So what was happening here is this. The generic builder on the personal toolbar
was allowing this assertion to be accepted into the local store. Wham-o, all of
a sudden everyone sees it. I removed the local store from the generic builder
for now: RJC will this break you in any way?
Comment 11•27 years ago
|
||
Doubt it... go for it.
| Assignee | ||
Updated•27 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 27 years ago
Resolution: --- → FIXED
Comment 12•27 years ago
|
||
[071699] can't get pop ups to appear, so I can't verify this one. It will have
to wait until I can duplicate the problem.
Updated•26 years ago
|
Whiteboard: fix ready to go → [07301999] pop ups don't work yet
Updated•26 years ago
|
Status: RESOLVED → VERIFIED
Whiteboard: [07301999] pop ups don't work yet
Comment 13•26 years ago
|
||
although it takes the pop-up a while to close, it did not obliterate the
toolbars
Updated•10 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•