Thanks @JoomliC
I link your Tracker back here:
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_id=8103&tracker_item_id=33327

Since you send the pull i move the Tracker to pending.
Thanks :)
You may blame the J!Tracker Application for transmitting this comment.

"Parent" may be a wrong name for the option actually. I'm not sure.
In german it's translated as "In same window", which is correct for the behavior.
Honestly I always expected it to work like this. Default option ("parent") stays in same window, otherwise you choose to open in a new window.

If we accept this PR, how would a user create an external link which opens in the same window/frame? That wouldn't be possible. Imho it would break existing behavior.

Hello!

"Default option ("parent") stays in same window, otherwise you choose to open in a new window."

This is exactly the problem i have today, if i set an external link to "parent" (in target window option) it is not opening in parent window/iframe, but in a new one.
Do you have tested an external link with current staging version ?
With adding the target="parent" in modules/modmenu/tmpl/default_url.php, it is not breaking existing behaviour, but solving it?
Or, do i'm alone to have this issue with parent ?... (tested on firefox, and without this PR, it's opening in a new tab, not the supposed parent frame)...

Thank you!
Cyril

When I use "parent", the link opens in the current window/frame like expected, since there is no "target" defined.
It doesn't break out of an iFrame, like one could assume from the naming of the option. But I suspect the error in the naming, not in the code

Maybe it's a setting in Firefox? Did you try with another browser?

Oh! You're right, it's not always an issue...

In fact, after testing more, to reproduce it in firefox, you can pin the tab (my error to not have tested this issue on a normal tab, not pinned).
Didn't thought that having a pinned tab could give this issue, and seems only in firefox. ;-)

So, assuming the fact firefox is a widely used browser, and pinned tabs used (more and more), is it an issue ?
In my opinion, adding target="_parent" is giving no broken behaviour, or i miss something...

" If we accept this PR, how would a user create an external link which opens in the same window/frame? That wouldn't be possible. Imho it would break existing behavior. "
Isn't supposed to be the purpose of a "parent" target ? With this PR, it is still possible to opens in the same window/frame... :-)
Why "parent" shouldn't be the right term for this ? (parent is "Opens the link in the parent frame" ?)
Maybe, it is missing the true "default" value "_self", as when target not specify, it is self, not parent.
Having so as options : Default (self) - Parent - New Window With Navigation - New Without Navigation ?

So today, you'r right, "parent" should be "self" ! ;-)

And "parent" should be added (as needed in some cases, and for example, when using this link inside an iframe)
What's your opinion ?
Should a edit (easy to do) this PR, by changing the parent to default, and adding a parent case ?

Cyril

Imho it's fine as it is without a specific target set. But the naming in english is confusing imho.

I don't think parent as a target is even needed. iFrames aren't used that much anymore, and if my menu is contained in an iFrame, then probably the whole site is. I would first make sure to escape my site from that iFrame and could care less if external links are opened within it or not

self would be an appropriate option. But why should I force a link to open in the same window (which is default anyway) for external links and for internal ones I use the default browser behavior? Makes no sense to me.

You might find the name parent confusing but that is the standard
terminology.
On 24 Feb 2014 12:40, "Thomas Hunziker" notifications@github.com wrote:

Imho it's fine as it is without a specific target set. But the naming in
english is confusing imho.

I don't think parent as a target is even needed. iFrames aren't used that
much anymore, and if my menu is contained in an iFrame, then probably the
whole site is. I would first make sure to escape my site from that iFrame
and could care less if external links are opened within it or not [image:
]

self would be an appropriate option. But why should I force a link to
open in the same window (which is default anyway) for external links and
for internal ones I use the default browser behavior? Makes no sense to me.

Reply to this email directly or view it on GitHub#3168 (comment)
.

" You might find the name parent confusing but that is the standard terminology. "

Hi Brian!
Not really... as far as i know, when target is not specified, it is by default self (not parent).
I agree that parent is not confusing, but in this case, target="_parent" is missing, and option default self, too.


_self: Opens the linked document in the same frame as it was clicked (this is default)
_parent: Opens the linked document in the parent frame


source: http://www.w3schools.com/TAGS/att_a_target.asp

I've added this PR because i'm facing this issue on a website, using sub-domains, and where i use iframe, but not only. The problem of the missing target is only in pinned tab on firefox.
Of course, i've done on my website an override of this in my html folder, in my template.
But a user with no skill with coding, could face an issue, and be able to open the link in the parent, if using pinned tab on firefox.

In fact, on firefox, if adding target="_self", it is doing the job, and for my purpose, parent of self is the same.

So that's why the question could be : Adding a default option (using browser default setting, meant to be self) and having parent with target="_parent" added as extra option ?

Best Regards,
Cyril

PS: @brianteeman i remember one of your tweet where you was disapointed with modal on iphone... This PR may interested you : #3169 ;)

Yes the default is self when not specified. I was just agreeing that parent can seem a strange word to describe its usage.

I can definitely see cases where you would need to use parent so thanks for contirbuting

You might find the name parent confusing but that is the standard terminology.

I'm not english native so can't argue much here. It may well be that it's clear for english folks.
In the german translation it says (freely translated) "In same Window", which is also not exactly true but is clear enough. Imho "default browser behavior" would be correct but it's to long

Default browser behaviour is self not parent

On 24 February 2014 16:34, Thomas Hunziker notifications@github.com wrote:

You might find the name parent confusing but that is the standard
terminology.

I'm not english native so can't argue much here. It may well be that it's
clear for english folks.
In the german translation it says (freely translated) "In same Window",
which is also not exactly true but is clear enough. Imho "default browser
behavior" would be correct but it's to long [image: ]

Reply to this email directly or view it on GitHub#3168 (comment)
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

So that's why the question could be : Adding a default option (using browser default setting, meant to be self) and having parent with target="_parent" added as extra option?

Adding a new option which opens in "_parent" would be a solution, yes.

Default browser behaviour is self not parent

Yep, and it's what the option does (and always did afaik).

Hi!

My proposal :
i close this PR, and create a new one with new options for targeting link.

Why? :
Modern browsers have new behaviour since tabs introduced in all of them. Target option is in a sense better in com_weblink or com_content than it is in menu type external link

Proposal :
Add the same options as used in other core components, in menu external link target option :

            <field name="target" type="list" default=""
                label="COM_WEBLINKS_FIELD_TARGET_LABEL" description="COM_WEBLINKS_FIELD_TARGET_DESC"
            >
                <option value="">JGLOBAL_USE_GLOBAL</option>
                <option value="0">JBROWSERTARGET_PARENT</option>
                <option value="1">JBROWSERTARGET_NEW</option>
                <option value="2">JBROWSERTARGET_POPUP</option>
                <option value="3">JBROWSERTARGET_MODAL</option>
            </field>

            <field name="width" type="text"
                class="inputbox validate-numeric" label="COM_WEBLINKS_FIELD_WIDTH_LABEL"
                description="COM_WEBLINKS_FIELD_WIDTH_DESC" />

            <field name="height" type="text"
                class="inputbox validate-numeric" label="COM_WEBLINKS_FIELD_HEIGHT_LABEL"
                description="COM_WEBLINKS_FIELD_HEIGHT_DESC" />

Doing the same for "external link" menu item type, seems to me the best way to improve and modernized the behaviour of this type of menu.

What's your opinion ?

Best regards,
Cyril

You probably can't use the exact same options because one of them uses JavaScript and not the target attribute. But adding more options and have them consistent with other places in core sure is a good thing.
You just have to make sure everything will behave the same after your PR. Also for 3rd party menu modules.

I close this PR.

I will take later a little time to make a new one, with more actual and modern options.
And will test to keep attention to do a clean integration and to keep all bahave the same after the PR.
@Bakual : Hi! i don't see an issue in adding modal as a target, and as it is already done in com_weblinks ?... Regards!

Cyril