218205 - links in the sidebar open in the main window instead of the sidebar

Status: VERIFIED INVALID

(Firefox :: General, defect)

Description

[Christopher Logan]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030829 Firebird/0.6.1+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030829 Firebird/0.6.1+

When creating a web sidebar for Firebird the html links will automatically open
up in the main window.  Which is not the way done in Mozilla where the target
must be set to _content

Reproducible: Always

Steps to Reproduce:
1.Create a html page with links
2.Open in Firebird
3.Create a bookmark
4.Right click the bookmark
5.Select Properties and check Load this bookmark in sidebar
6.Click the bookmark
7.Then click the link in the sidebar

Actual Results:  
The link opens in the main window without being told to and not just the sidebar

Expected Results:  
Loaded the link in the sidebar

This should be fixed before Firebird 0.7 is released with Sidebar support.

Comment 1

[Christopher Logan]

There is a fix for this it just needs to be added to browser.js
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/browser/base/content&command=DIFF_FRAMESET&file=browser.js&rev1=1.209&rev2=1.210&root=/cvsroot
it would require that _main be used to open a link in the main window.
And every link without target="_main" will open in the sidebar.

Comment 2

[Steffen Wilberg]

Christopher, bonsai shows the differences in the Mozilla (and Firebird etc.)
sourcecode from one checkin to another. In other words, your link shows code
that was already checked in.
It was modified a couple of times in the meantime, especially here:
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/browser/base/content&command=DIFF_FRAMESET&file=browser.js&rev2=1.222&rev1=1.221

The current version is here:
http://lxr.mozilla.org/mozilla/source/browser/base/content/browser.js#3777

Comment 3

[Steffen Wilberg]

From the comments in the source:

1. A Web panel's links should target the main content area.
2. rel = "sidebar": This is the Opera convention for a special link that - when
clicked - allows you to add a sidebar panel.
3. target = "_search": Used in WinIE as a way of transiently loading pages in a
sidebar.  We mimic that WinIE functionality here and also load the page transiently.

This is the intended behaviour therefore.
But it's on Hyatt to decide.

Comment 4

[Christopher Logan]

Those changes would work, but it would also break the current sidebars that are 
already been made for Mozilla.  Not that I care I just want to be able to create 
one and have the content stay inside, but just something to think about.

Comment 5

[Ondrej Brablc]

A link without a target attribute opens in all browsers in the same window (that
is general rule valid not only for sidebars), tested with: Opera Sidebar
Hotlist, Mozilla 1.x, Internet Explorer 5.5, 6.0 (valid for Explorer Bars opened
from menu and using _search target).

To open the link in the main browser window following target can be used:

'_main': Opera, Internet Explorer
'_target': Mozilla

You do not follow any of the above nor any combination of it - it must be
considered as bug. 

There is no target that can be used to load in the same window, _search cannot
be used, because IE can have sidebars (Explorer Bars) created as Active X (just
registry change) and their address is not _search. 

My experience comes from http://www.sitebar.org project (3.0 version).

Comment 6

[Brendan Eich [:brendan]]

Re: comment 5 -- Mozilla now supports "_main" target, a la IE (NB: not case
insensitive).  I don't know what source led you to think "_target" means
anything special.  http://lxr.mozilla.org/mozilla/search?string=%22_target%22
shows only two hits, no C++ support.  AFAIK Mozilla has never supported a
"_target" target, and I'm not sure what that name would mean.

/be

Comment 7

[Ondrej Brablc]

Re: comment 6 -- Sorry for the mistake, it should have been "_content" instead
of "_target". 

What you say would be nice, that is _main treated as _content (which should be
still supported), however missing target can ***never*** be interpreted as _content.

Comment 8

[Brendan Eich [:brendan]]

I didn't say _main should be treated as _content (or that a missing target
should be, either).  I merely noted that Mozilla supports _main now, contrary to
what comment 5 said.

/be

Comment 9

[Simon Paquet [:sipaq]]

According to
http://lxr.mozilla.org/mozilla/source/browser/base/content/browser.js#3655 this
is the intended behaviour:

"A Web panel's links should target the main content area.  Do this if no
modifier keys are down and if there's no target or the target equals _main (the
IE convention) or _content (the Mozilla convention)."

Therefore marking INVALID.

Comment 10

[Simon Paquet [:sipaq]]

verified.

Comment 11

[Ondrej Brablc]

I miss any arguments here in the comments, please allow some questions:

1) Do you recommend Web panel authors to use _self instead of empty target?
2) Will you go further and make behaviour of target on <form> consistent with
that of <a>?
3) Why do you want existing Web panels for Internet Explorer, Opera and Mozilla
to be broken in Mozilla Firebird?
4) What exactly have been verified when closing this bug? That the behaviour
corresponds to the code? I can verify 90% of bugs this way even without looking
into the code, you should have verified it agains your goals: "... our goal is
to be the best browsing solution on Windows and Linux ...". You will not achieve
this by breaking existing sidebar applications.

IMHO it would be 100% enough to make _main synonym for _content.

I'm really no Mozilla expert, I just fell in love with Mozilla Firebird and it
starts to behave like wife 20 years after wedding. Anyway, thank you for Mozilla
Firebird. If you can afford to break existing sidebar applications I will use
<base target="_self"> and hope it will not open in the main window.

Comment 12

[u63580]

*** Bug 245977 has been marked as a duplicate of this bug. ***