$(document).ready(function () { //FIXME It's not a good idea to modify the click events + $('#searchresults table tr a[href*="/detail.pl"]').on('click auxclick', function (ev) {
Created attachment 102144 [details] [review] Bug 25027: Use localStorage instead of sessionStorage for results browser Staff side, when a search a done and a result clicked, a browser appears on the left, to navigate between the different results. We use sessionStorage to know the list of biblionumber from the result. As sessionStorage is only for the current tab, we do some ugly things, to catch the click events, then open the new tab, attach it to the current window, and put the focus back on the result list. We really should not do that, and let the user decide what they want to do with their clicks! To do so, let use the correct storage, localStorage, and have the results shared between the windows. We may need to clear that at some point, isn't it? Test plan: Launch a search, click result (left or middle), confirm you see the browser and that the window/tab opened like any other websites (depending on your web browser settings).
(In reply to Jonathan Druart from comment #1) > We may need to clear that at some point, isn't it? Ignore that, that's done already. We keep 20 searches.
Created attachment 102252 [details] [review] Bug 25027: Use localStorage instead of sessionStorage for results browser Staff side, when a search a done and a result clicked, a browser appears on the left, to navigate between the different results. We use sessionStorage to know the list of biblionumber from the result. As sessionStorage is only for the current tab, we do some ugly things, to catch the click events, then open the new tab, attach it to the current window, and put the focus back on the result list. We really should not do that, and let the user decide what they want to do with their clicks! To do so, let use the correct storage, localStorage, and have the results shared between the windows. We may need to clear that at some point, isn't it? Test plan: Launch a search, click result (left or middle), confirm you see the browser and that the window/tab opened like any other websites (depending on your web browser settings). Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Created attachment 102446 [details] [review] Bug 25027: Use localStorage instead of sessionStorage for results browser Staff side, when a search a done and a result clicked, a browser appears on the left, to navigate between the different results. We use sessionStorage to know the list of biblionumber from the result. As sessionStorage is only for the current tab, we do some ugly things, to catch the click events, then open the new tab, attach it to the current window, and put the focus back on the result list. We really should not do that, and let the user decide what they want to do with their clicks! To do so, let use the correct storage, localStorage, and have the results shared between the windows. We may need to clear that at some point, isn't it? Test plan: Launch a search, click result (left or middle), confirm you see the browser and that the window/tab opened like any other websites (depending on your web browser settings). Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Nice work everyone! Pushed to master for 20.05
backported to 19.11.x for 19.11.06
backported to 19.05.x for 19.05.11