790893 - Chinese conversion script opens blank tab instead

Status: RESOLVED INVALID

(Tech Evangelism Graveyard :: Chinese-Traditional, defect)

Description

[eeled]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0.1
Build ID: 20120905151427

Steps to reproduce:

http://www.lcread.com/bookPage/237882/index.html
On that website, I tried clicking the two chinese characters on the top-right (繁體）. It's supposed to convert the simplified Chinese into traditional.


Actual results:

It opened a blank tab instead.


Expected results:

It's supposed to convert the simplified Chinese into traditional.

Comment 1

[Alice0775 White]

I think this is site problem.

The site describes <base target="_blank">.
So, the link target automatically set "_blank"(ie. the link will open in a newtab),then  the link href="javascript:StranBody()" fails to execute.

Comment 2

[Hallvord R. M. Steen]

I disagree that this is an evangelism issue. The browser should ignore target=_blank for javascript: links.

Comment 3

[Hallvord R. M. Steen]

Attachment: test case

Comment 4

[Hallvord R. M. Steen]

Chromium ignores target=_blank here. Needs testing to ser if it is also ignored when set directly on the link.

Comment 5

[Boris Zbarsky [:bzbarsky]]

> The browser should ignore target=_blank for javascript: links.

Er... no, it should not.  Consider the trivial case of "javascript:'hey there'" which produces a new document!

Looks like Chrome screws that up, by the way, and shows the new document in the same navigation context as the old document even if the target is set.  I believe this is a bug in Chrome (and in the spec if it requires this behavior).

Comment 6

[Boris Zbarsky [:bzbarsky]]

And fwiw, I see nothing in the spec at http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#following-hyperlinks-0 that special-cases "javascript:" in step 3.  And section 4.12.2 says that activation behavior is either to "follow the hyperlink" or "download the hyperlink".  So Chrome is in fact not matching the spec here.

Comment 7

[Hallvord R. M. Steen]

Either way has its merits. However, I do believe that 

a) Returning a new string to create a document is less common for a javascript: url than calling some method in the page 

b) The failure condition if we ignore target=_blank for a new document string is easy for users to recover from - just use back button - whereas no normal user can make a page that defaults to open a new TAB with a dysfunctional javascript: url work. 

Hence I think ignoring target is a more useful and compatible approach, I think Chrome does this om purpose (and might be unlikely to change) and that we should consider changing the spe accordingly. I'm happy to ask the site for a fix, but IMO we should also make a core fix to avoid this hurting us again in the future. What do you think, bz?

Comment 8

[Boris Zbarsky [:bzbarsky]]

> I think Chrome does this om purpose

I actually highly doubt that.  I think it falls out of the fact that WebKit does not treat javascript: like URIs at all.  It doesn't follow any of the normal URI-loading codepaths in WebKit.

Unless you propose that everyone else duplicate the various WebKit insanity surrounding javascript:, I think it makes a lot more sense and is a lot less surprising to web authors to have javascript: behave like a URI load.

Comment 9

[Hallvord R. M. Steen [:hallvors]]

I wasn't arguing it was better for *web authors*, my argument was from an end user point of view. (That said, even authors running a largeish site probably don't expect to break some random javascript: links somewhere if they decide to add a global <BASE target=_blank> tag to some template..). And I know all developers think "consistency" is user-friendly, but they may not always understand what behaviour others find "consistent" ;-)

Anyway, seems there is no chance of changing your mind so I'll just end the discussion in order to contact the site.

Comment 10

[Hallvord R. M. Steen [:hallvors]]

This issue (which IMHO still is a core bug that should be fixed in engine and if required in the spec for compat..) breaks or hampers video playback on elpais.com. Some JS apparently sets a target="_blank" attribute on a javascript: link that wraps the "view video" button:

http://ep01.epimg.net/m/js/comun.js

        if ('MozActivity' in window)  { // Firefox OS    
            activaBotonAtras();

            var enlaces = document.getElementsByTagName("a");
            var total_enlaces = enlaces.length;
            for ( i = 0 ; i < total_enlaces ; i++ ) {  // los enlaces que no son de EL PAÍS se tienen que abrir "fuera"
                if ( ! enlaces[i].getAttribute("href").match("/m/") ) 
                    enlaces[i].setAttribute("target","_blank"); 
                    else  
                    enlaces[i].setAttribute("target","_self"); 
            }


so tapping the video to start it makes the browser open a new tab for this javascript:void(0) URL:


	<a tabindex="20" target="_blank" class="posicionador" id="posicionador_1377758184_726257_1377857041" title="Ver vídeo" href="javascript:void(0)">
		<span class="boton_video"></span>

(Bug 410623 is also related to this one in its own convoluted way)

Comment 11

[Boris Zbarsky [:bzbarsky]]

It might be worth it to treat javascript:void(0) like we do loads that result in a download for purposes of target=_blank.

Comment 12

[Hallvord R. M. Steen [:hallvors]]

(In reply to Boris Zbarsky [:bz] from comment #11)
> It might be worth it to treat javascript:void(0) like we do loads that
> result in a download for purposes of target=_blank.

Cool - that should sort out most of these problems. I reported bug 911746 to follow up your suggestion.

Comment 13

[Karl Dubost💡 :karlcow]

The URL doesn't exist anymore. If you find an equivalent page exhibiting this issue on this site, please reopen and propose the new URL. closing as INVALID.