247505 - bookmarklets can't be loaded in the sidebar

Status: RESOLVED WONTFIX

(Firefox :: Bookmarks & History, enhancement)

Description

[Tomer Cohen :tomer]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040615 Firefox/0.9
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040615 Firefox/0.9

I made a javascript bookmarklet couple of time ago, which uses the getSelection
method to get selected text from the browser, as input. Than, I've been asked to
port that code to a sidebar. For the portability and simplifity, I wish to make
it as a regular sidebar, rather than extension. 

I replaced the "window.open" by "location.href=", which works quite well in the
browser window, but it can't work in the sidebar, as the browser load the
javascript url from seperated browser environment.

Reproducible: Always
Steps to Reproduce:
Look at the attached testcase. The first two codes works well, but the third
work only in the browser, not on the sidebar.


Expected Results:  
javascript: URLs should load on the browser, but with target=-moz-sidebar.
(There is no -moz-sidebar property currently, but maybe this is required to
reslove this bug.)

Also note that Internet Explorer have target=_search, which can be used there
for the built-in toolbar, so we can make a cross-browser solution with
implementing target=_search for Mozilla.

Comment 1

[Tomer Cohen :tomer]

Attachment: HTML+JS testcase

Comment 2

[Mike Connor [:mconnor]]

er, don't we have target="_search" already?  hyatt implemented that around 1.5, iirc

Comment 3

[Tomer Cohen :tomer]

You right. target=_search was implemented for Web Panels. 

But still, I see no point to load javascript: URLs in the sidebar, while most of
them will need to manipulate data from the browser main content area. 

Comment 4

[Mike Connor [:mconnor]]

if you want to manipulate data in the content area from the sidebar, you'll need
to implement this as a chrome extension.  The current security model doesn't
allow for HTML from the sidebar to access HTML from the content area (for good
reason).

Comment 5

[Tomer Cohen :tomer]

(In reply to comment #4)
> if you want to manipulate data in the content area from the sidebar, you'll need
> to implement this as a chrome extension.  The current security model doesn't
> allow for HTML from the sidebar to access HTML from the content area (for good
> reason).

Javascript bookmarklets with the same code *can* be executed from the browser
content area, but than can't access the sidebar for output. 

My point is that instead of opening those URLs in the sidebar, open them in the
same browser content area, but connect them to the sidebar for output (this way,
location.href and document.write won't change the content area but the sidebar).

Comment 6

[Asaf Romano (gone)]

confirming as enhancement.

Comment 7

[M Laplante]

I accidentally got this to work some of the time (!)  In the "Babylon Sidebar
(not working at all)" example, change the first "window.getSelection()" to
"_content.document.getSelection()".  This will usually read the selected text,
but it works only once per session.  The second time the JavaScript console
tells me "Error: uncaught exception: Permission denied to get property
HTMLDocument.getSelection".

Here is where it gets mysterious.  Some sidebar bookmarks, including the
Bugzilla sidebar ( https://bugzilla.mozilla.org/sidebar.cgi ) will re-set the
it, so it you alternate between the bugzilla sidebar and the modified Babylon
one above, the bookmarklet script can be used without this error.

I have found other cases where the getSelection method (among others) can pass
the main window document information to the sidebar this way, but not as easily
reproducible.  It's still not the sidebar reading the document, just the
bookmarklet, but the security model is inconsistent.  In my opinion,
bookmarklets should be able to read main content properties and then open a
document in the sidebar.

Comment 8

[Mike Connor [:mconnor]]

sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change

Comment 9

[Gervase Markham [:gerv]]

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv

Comment 10

[Jared Wein [:jaws] (please needinfo? me)]

We don't have plans to support the sidebar much longer (bug 842642) and so adding features to the sidebar doesn't seem like a good use of time.