57864 - window._content insufficient for sidebar apps; need _active

Status: NEW

(SeaMonkey :: Sidebar, defect, P3)

Description

[Joseph Elwell]

Some sidebar applications use window._content to load URLs into the Browser 
window. Currently window._content points to any window's content area. It is 
unclear whether this was by design. But Sidebar developers need a clear way to 
say "Load this URL in a *BROWSER* window (and open one if none are available)".

Many applications that are currently written break Composer when they assign to 
window._content. In this case the URL is loaded into Composer's content window - 
losing any data that was in the Composer window.

It should also be noted that Sidebar tabs are applications. They should be able 
to do whatever - no matter how destructive - they want; including loading into 
editor windows...

Comment 1

[Scott Collins]

It seems like the current behavior of assigning to |window._content.location| is
probably right, but we need a scheme, callable from a sandboxed app, to open new
content in either the top-most acceptable content area for that content type, or
else a new window.

Comment 2

[Dan M]

  Yes, we've had plans for a long time to implement a JS function, probably 
window._active(windowtype), to return the equivalent of window._content of the 
most recently active (topmost) window of type (windowtype), where windowtype is 
the same thing as in WindowMediator. Or at least a window._active, which assumes 
a browser window.
  From chrome, of course, you can just use the WindowMediator. It's more arcane, 
but it works. Sidebar panels in particular are rather aching for this. Targetting 
mozilla 1.0 for now and adding "helpwanted." The task is described and fairly 
straightforward to do, if anyone is out there and interested.

Comment 3

[shrirang khanzode]

spam : changing qa to sujay (New Sidebar QA)

Comment 4

[Jesse Ruderman]

>It should also be noted that Sidebar tabs are applications. They should be 
>able to do whatever - no matter how destructive - they want; including loading 
>into editor windows...

I was under the impression that "normal" sidebar tabs were supposed to have 
only as much power as a normal webpage.  Sidebar tabs that want to do extra 
things, like list the links on the current page, have to be installed rather 
than simply added to the sidebar.  Cf discussion in bug 59603.

I think the best solution to this bug is to fix _content to do what sidebar 
authors expect it to do, which is to open in a browser window (and not an 
editor window).  According to bug 27162, that should also be the default target 
for sidebar links.

Comment 5

[Jesse Ruderman]

Does this bug lead to data loss whenever Composer is open (and the user hits a 
target=_content link in any sidebar), or only when the sidebar is in the 
Composer window?

Comment 6

[Dan M]

  Jesse: I haven't looked at this in a while. Memory seems to be telling me that 
the meaning of _content is overloaded. Composer code uses it to mean the content 
docshell of the composer window. Sidebar code uses it to mean the content 
docshell of the same window. Both are correct, but when sidebar happens in a 
Composer window, bad things happen.
  In *my* opinion the best thing to do is not have any stinking sidebars in the 
composer window. They don't belong there; they go in browser windows. But I think 
we've suggested that before, too, and got nowhere with it.

Comment 7

[Neil Pryde]

What about setting window._content to your own browser window? Can that be done?

Comment 8

[Neil Pryde]

CC Spam

Comment 9

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 10

[Arun Prasannan (polar)]

This bug is being marked EXPIRED as it has seen no activity in a very long time.

If you think that the issue reported might still be relevant, please test with a recent release of SeaMonkey and if the problem persists feel free to re-open the report. Thank you.

http://www.seamonkey-project.org/

Comment 11

[Arun Prasannan (polar)]

This bug is being marked EXPIRED as it has seen no activity in a very long time.

If you think that the issue reported might still be relevant, please test with a recent release of SeaMonkey and if the problem persists feel free to re-open the report. Thank you.

http://www.seamonkey-project.org/

Comment 12

[Mark Banner (:standard8)]

Bulk reopening incorrectly expired bugs - no activity does not constitute no bug - these need proper checking.