Control-Click (PC) or Command-Click normally opens any link in a web browser into a new tab. After the 3.14 upgrade, we have discovered inconsistency in links not always having this behavior anymore on search.pl and detail.pl. This has been replicated on Master as well. On search.pl, control-clicking or command-clicking on the title links opens the link in the same window. You have to actually right-click on the link and tell the browser to open the link in a new tab. The linked author field in the search results, the call numbers, the facets on the left-hand side of the screen, the links at the top -- all will open in a new tab with the control-click or command-click option. On detail.pl, if the back to search results/next record/previous record links are present, control-clicking or command-clicking the normal/MARC/ISBD/Items/Holds/Checkout History/Barcode links open the information on the same screen. If you switch to one of the other tabs, the back to search results link is gone, and this keyboard shortcut works again. I do not see this same behavior in the OPAC. Disabling all javascript causes it to return to normal.
(In reply to Ed Veal from comment #0) > On search.pl, control-clicking or command-clicking on the title links opens > the link in the same window. How do you reproduce this problem? I'm not seeing it in master using Firefox. > Disabling all javascript causes it to return to normal. This would imply that a JavaScript error on the page is to blame. Does your browser report any JavaScript errors?
On a fresh Ubuntu package install of 3.18.3 and on a fresh kohadevbox I imported two records from LOC (Beyond Lies the Wub and Ubik, both by Philip K Dick) Rebuild zebra search for "Philip" Control+clicking title in search results opens in current tab in Firefox and Chrome, all other links on the page open in a new tab on control+click The only javascript error I see is an Uncaught TypeError: undefined is not a function
Created attachment 38480 [details] [review] Bug 11890: Click events on titles does not work as expected The browse results feature (bug 10404) modified the click events on titles on the search result page (intranet). It introduced bad behaviors: 1/ ctrl+click on a title does not open a new tab 2/ middle click on a title does open a new tab but the browser is not displayed. Note that this patch is not perfect, it fixes the 2 bad behaviors but the ctrl+click gives the focus to the new tab (could go against the preferences of the users). Test plan: 1/ On the staff interface, launch a search (catalogue/search.pl?q=XXX) 2/ When middle-clicking on a title, a new tab should open. On this tab the browse result feature should be displayed 3/ Same for cltr+click
Created attachment 38502 [details] [review] [SIGNED OFF] Bug 11890: Click events on titles does not work as expected The browse results feature (bug 10404) modified the click events on titles on the search result page (intranet). It introduced bad behaviors: 1/ ctrl+click on a title does not open a new tab 2/ middle click on a title does open a new tab but the browser is not displayed. Note that this patch is not perfect, it fixes the 2 bad behaviors but the ctrl+click gives the focus to the new tab (could go against the preferences of the users). Test plan: 1/ On the staff interface, launch a search (catalogue/search.pl?q=XXX) 2/ When middle-clicking on a title, a new tab should open. On this tab the browse result feature should be displayed 3/ Same for cltr+click Signed-off-by: Nick Clemens <nick@quecheelibrary.org>
> Note that this patch is not perfect, it fixes the 2 bad behaviors but > the ctrl+click gives the focus to the new tab (could go against the > preferences of the users). This is a huge improvement so signing off, would it seem ungrateful to file the above as a new bug?
(In reply to Nick Clemens from comment #5) > > Note that this patch is not perfect, it fixes the 2 bad behaviors but > > the ctrl+click gives the focus to the new tab (could go against the > > preferences of the users). > > This is a huge improvement so signing off, would it seem ungrateful to file > the above as a new bug? Not at all, feel free to do it :)
I am sorry, but this doesn't seem to work correctly: Without patch: - Search for something - From the result list, click on any record - Verify the result browser is shown on the left With patch: - Search for the same something as above - From result list, click on the same record - Verify the result browser is missing
Created attachment 38640 [details] [review] Bug 11890: Prevent default on click event It seems that the previous patch does not stop the propagation of the event if the link is clicked with the left button (which=1).
(In reply to Katrin Fischer from comment #7) > I am sorry, but this doesn't seem to work correctly: > > Without patch: > - Search for something > - From the result list, click on any record > - Verify the result browser is shown on the left > > With patch: > - Search for the same something as above > - From result list, click on the same record > - Verify the result browser is missing Good to have a QA step :) Sorry about that, I am sure I tested this case, the trivial one! (but it seems not with this code...)
OPAC view: Open in new window. still opens in the same tab for me :(
(In reply to Katrin Fischer from comment #10) > OPAC view: Open in new window. still opens in the same tab for me :( Please detail, what does not work? Clicking on what and how (middle click, left click, ctrl+click)? I confirm it works here.
After sleeping over it, I think it might be out of scope of the bug. But there is another bug related to the link rewriting: If you set your OpacBaseUrl we display a link to the OPAC in the details page, that opens in a new tab by default - but currently this doesn't work.
Created attachment 38782 [details] [review] [PASSED QA] Bug 11890: Click events on titles does not work as expected The browse results feature (bug 10404) modified the click events on titles on the search result page (intranet). It introduced bad behaviors: 1/ ctrl+click on a title does not open a new tab 2/ middle click on a title does open a new tab but the browser is not displayed. Note that this patch is not perfect, it fixes the 2 bad behaviors but the ctrl+click gives the focus to the new tab (could go against the preferences of the users). Test plan: 1/ On the staff interface, launch a search (catalogue/search.pl?q=XXX) 2/ When middle-clicking on a title, a new tab should open. On this tab the browse result feature should be displayed 3/ Same for cltr+click Signed-off-by: Nick Clemens <nick@quecheelibrary.org> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Created attachment 38783 [details] [review] [PASSED QA] Bug 11890: Prevent default on click event It seems that the previous patch does not stop the propagation of the event if the link is clicked with the left button (which=1). Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Improves behaviour, but there are still some problems: - left click open in new tab is missing the browser
Patches pushed to master. Thanks Jonathan!
Pushed to 3.18.x will be in 3.18.7