webclient: Opening link in a new tab from the catalog forces user out of client

Bug #1538675 reported by Kathy Lussier
78
This bug affects 16 people
Affects Status Importance Assigned to Milestone
Evergreen
Confirmed
Medium
Unassigned

Bug Description

I'm guessing this is a side effect of embedding the catalog in an iframe. When using the catalog in the web client, if the user chooses to open a link in a new tab, the user leaves the iframe and loses all of the client navigation menus.

Preferred behavior would be for those links to stay in the iframe when opened in a new tab. Being able to open links in a new tab from a search results page can be very handy for staff.

Changed in evergreen:
status: New → Confirmed
Kathy Lussier (klussier)
Changed in evergreen:
importance: Undecided → Medium
Revision history for this message
Jeff Davis (jdavis-sitka) wrote :

If I understand correctly, we use an onchange event handler to make catalog links work within the web client. Clicking a link in the catalog iframe triggers onchange, which calls the handle_page function, which intercepts the click and loads the appropriate staff client page. But opening a link in a new tab/window appears to bypass the event handler.

Generally, you open a link in a new tab/window via the context menu. So I wonder if we could modify the opac_iframe DOM (or add some ctx.is_staff code to the appropriate OPAC templates??) so that, for links matching certain patterns, invoking the context menu would display a custom menu with appropriate actions for that link pattern. For example, right-clicking a link of the form /opac/record/(\d+)/ would display a menu with an option "View record in new tab", which loads /staff/cat/catalog/record/$1 in a new tab.

The handle_page function already does pattern matching on links within opac_iframe, and the client accesses opac_iframe.dom.contentWindow for stuff like search result hit counts, so hopefully it's not a completely crazy idea. :)

Revision history for this message
Jeff Davis (jdavis-sitka) wrote :

There was some discussion of better solutions during today's developer meeting:

http://irc.evergreen-ils.org/evergreen/2018-04-04#i_353755

Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

EG 3.3.4

Another effect of this issue that we have noticed is that when staff open bib results in new tabs, and then view those tabs and decide to place a hold, the hold gets placed without a customers notifications preferences being used.

This was a long awaited workflow that they were looking forward to with the web staff client, since many staff are used to opening links from search results in new tabs in general in a web browser (for google searches for example). Then looking at each tab, deciding if the title/info is what they are looking for, and placing a hold, or closing the tab.

It seems that the staff.js file is missing some prerequisites when the place hold page is loaded in in a new tab.

Josh

Revision history for this message
Benjamin Kalish (bkalish) wrote :

We encounter this frequently. Staff are used to ctrl-clicking on links to open them in new windows, and it works as expected in most of the web client. The fact that it doesn't work here comes as an unpleasant surprise, sometimes even to staff who have encountered it before. And so far as I can tell there is no workaround that makes good of staff time.

Revision history for this message
Terran McCanna (tmccanna) wrote :

Adding note that this is not a problem with the new experimental Angular staff catalog.

tags: added: usability
removed: webstaffclient
Gina Monti (gmonti90)
tags: added: performance
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.