GNOME Bugzilla – Bug 114949
Middle click on urls and target attribute behavior
Last modified: 2012-12-11 10:17:27 UTC
When clicking middle mouse button on href link the page usually opens in new tab. Sometimes webdesigners use Javascript to open fixed size window for images and stuff. In Ephy when clicking middle mouse button on such link it opens an empty new tab and does not execute href Javascript at all. Clicking with left mouse button it executes the Javascript code and everything is as fine as it can be. This used to well in Galeon. An example code from some website: ... function OpenImage(nickname,end,img_number) { NewWindow = window.open("openimage.php?nickname="+nickname+"&end="+end+"&img_number="+img_number,"","resizable=no,toolbar=0,location=0,directories=0,status=0,menubar=0,scrollbars=1,copyhistory=0,width=450,height=450") NewWindow.focus(); } ... <a href="javascript:OpenImage('someimage','.jpg','3');"><b>someone</b></a> ...
Would be interesting to know what mozilla does.
I just tested this with mozilla-1.4-12 and epiphany-0.7.3-3, it does not work with either of those. However this seems to work like a charm with mozilla-1.0.1-26 and galeon-1.2.6-0.8.0, when configured as "Middle click opens tab into new tab" and "Open popups in tabs". So, we actually have two problems here: a) Feature missing; "Open popups in tabs". As we are on feature freeze, we won't see this really soon. However I would like to see this implemented asap. :) b) A bug; Ephy opens new tab if middle clicked on javascript link. It should either ignore middle click on javascript links, or behave like left button was clicked instead of middle.
Here's a link to my Epiphany testing page. It contains a test case for this bug too: http://www.peelo.com/epiphany-testing.html
This bug is related to bug 115134 which is about broken "middle click opens in tabs" support for target="_blank".
Checked in a patch that doesnt open in new window javascript:. The other part of the testcase is a lot more complex to fix, post 1.0.
What's left on this bug? I tried the testcase, and the first column is all working as expected. Middle button now _always_ opens in new tab, except for javascript: links, so the 2nd column rows 1-3 open in new tab, and rows 4+5 open in new/existing window. The 3rd and 4th column don't apply any more, since the "open in new tabs" pref is gone. -> FIXED ?
Try pressing Click 5 with left button; it opens the URL into new window, but also changes the content of the original tab/window. Not good.
Created attachment 24200 [details] [review] fix
The patch leave click handling up to mozilla in this case. Chpe can you review ? Dave, if you click on a javascript link with middle button what you think is the better behavior ? Opening the javascript in another window doesnt make much sense but should we ignore the click or behave like if it was a normal click ? Much of an academic issue, since it's all up to mozilla anyway.
The behavior we get with the patch is dont take any action btw.
I wonder if a statusbar message would make sense. "The link cannot be opened in a new tab".
Patch looks good.
> ------- Additional Comments From Toni Willberg 2004-01-28 12:17 ------- > Try pressing Click 5 with left button; it opens the URL into ne > window, but also changes the content of the original tab/window. Not > good. I just tried it with mozilla, and it does the same! Isn't this just a problem with not using void(....) around the expression?
/me sucks with edgy cases...I don't know...I really don't think we should completely overide web designers with the tabs thing. I too have been annoyed by getting an empty tab when middle clicking a javascript link. perhaps the best thing is to just run the javascript on middle click and let it do its thing and not open a new blank tab. Sure ten people will complain that they want everything to open in new tabs but bah...
We decided to not open and put a statusbar message. I cant add the message right now because we are freezed. Just checking in my patch for now ...
The URL field has been removed from bugzilla.gnome.org. This URL was in the old URL field, and is being added as a comment so that the data is not lost. Please email bugmaster@gnome.org if you have any questions. URL: http://www.peelo.com/epiphany-testing.html
Comment on attachment 24200 [details] [review] fix This patch was committed.
> We decided to not open and put a statusbar message. I cant add the > message right now because we are freezed. Just checking in my patch > for now ... String freeze is finished, can we move on this now?
In string freeze again, moving Target Milestone to 1.6.
Mass reassigning of Epiphany bugs to epiphany-maint@b.g.o
We're not in string freeze anymore; removing the BLOCKED_BY_FREEZE keyword.
Target Milestone: 1.6 -> 1.8
Target: 1.8 -> 1.10 due to feature and UI freeze.
chpe, can we take a decision on this before 1.10 feature/ui freeze?
This bug is not a good candidate for use of the "Gnome target" field. This field is not a 'it would be nice' field, it's a 'Gnome releases may need to be delayed for this issue' field. It's intended for use by senior-ish bug triagers and the release team. Since this bug is not critical enough to delay a release of the entire desktop the designation has been removed. The 'Target Milestone' field is meant to be used to describe the version of the product that developers or the maintainers believe they should fix the bug by.
Mass changing target 2.16 -> 2.18
Does anyone have testcase for this bug?
WIP at bug 607233 *** This bug has been marked as a duplicate of bug 607233 ***