Bug 25027 - Result browser should not overload onclick event
Summary: Result browser should not overload onclick event
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Staff interface (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Jonathan Druart
QA Contact: Testopia
URL:
Keywords:
Depends on: 23601
Blocks: 26562
  Show dependency treegraph
 
Reported: 2020-03-31 14:38 UTC by Jonathan Druart
Modified: 2021-06-14 21:30 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Small patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
20.05.00, 19.11.06, 19.05.11


Attachments
Bug 25027: Use localStorage instead of sessionStorage for results browser (3.13 KB, patch)
2020-03-31 14:44 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 25027: Use localStorage instead of sessionStorage for results browser (3.18 KB, patch)
2020-04-01 20:08 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 25027: Use localStorage instead of sessionStorage for results browser (3.24 KB, patch)
2020-04-06 13:51 UTC, Nick Clemens
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Druart 2020-03-31 14:38:35 UTC
$(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) {
Comment 1 Jonathan Druart 2020-03-31 14:44:39 UTC
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).
Comment 2 Jonathan Druart 2020-03-31 14:46:24 UTC
(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.
Comment 3 Owen Leonard 2020-04-01 20:08:16 UTC
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>
Comment 4 Nick Clemens 2020-04-06 13:51:32 UTC
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>
Comment 5 Martin Renvoize 2020-04-14 15:07:48 UTC
Nice work everyone!

Pushed to master for 20.05
Comment 6 Joy Nelson 2020-05-05 21:10:19 UTC
backported to 19.11.x for 19.11.06
Comment 7 Lucas Gass 2020-05-13 22:17:45 UTC
backported to 19.05.x for 19.05.11