Staff client initial login screen

Bug #609326 reported by Anoop Atre on 2010-07-23
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Evergreen
Low
Dan Wells

Bug Description

Evergreen: 1.6.0.6
OpenSRF: 1.2.2
PostgreSQL: 8.4
Server: Ubuntu Hardy
Desktop: Ubuntu Karmic
XULRunner: 1.9.2.7 - 20100716155810
Client Version: 1.6.0.6/1.6.0.4

Tabs in the staff client are missing the tab close icon with new xulrunner, only option is to use ctrl+w to close tab.

> Tabs in the staff client are missing the tab close icon with new
> xulrunner, only option is to use ctrl+w to close tab.

Or File->Close Tab from the top-level menu.

Yeah, I'm not sure what sort of debate has been happening in the
Mozilla community with this, but from what I understood a long time
ago, most of the functional enhancements for tabbox/tabbrowser were
Firefox specific, and did not make sense outside of that context. So
it's a probably a sort of throw the baby out with the bathwater
scenario, where xulrunner gets stocked with a minimal tab browser, and
Firefox does their own thing.

We can could take some of the code from the older xulrunner:

<hbox class="tabs-closebutton-box" align="center" pack="end">
<toolbarbutton ondblclick="event.stopPropagation();"
class="tabs-closebutton close-button"
xbl:inherits="disabled=disableclose,oncommand=onclosetab"
xmlns:xbl="http://www.mozilla.org/xbl"
oncommand="g.menu.close_tab()"/>
</hbox>

But just shoving that in menu_frame_overlay.xul:<tabs></tabs> is kind
of brittle (especially if we try to put it next some of the anonymous
nodes that XBL uses to construct the element--such things are prone to
changing as we've seen), and we'd also need to disable it whenever we
were down to just one tab.

We could roll our own implementation of tabbox, but I don't think it's
worth it. May be better to wade into the Mozilla community and see
what's up.

-- Jason

Jason Etheridge (phasefx) wrote :

> We could roll our own implementation of tabbox, but I don't think it's
> worth it.  May be better to wade into the Mozilla community and see
> what's up.

https://bugzilla.mozilla.org/show_bug.cgi?id=534221

James Fournie (jfournie) on 2010-08-31
Changed in evergreen:
status: New → Confirmed
importance: Undecided → Low
Dan Wells (dbw2) wrote :

While there is a different fix in the 2.1/trunk client, I have committed a fix for this in the 2.0 client here:

http://svn.open-ils.org/trac/ILS/changeset/19757

I think this is probably worth backporting to 1.6, but wanted to give a chance for feedback first. This is more or less what Jason had suggested, but since this is outside the <tabs /> container, I don't think this is particularly brittle (could be wrong), and also, no need to disable when down to one tab as it harmlessly spawns a new tab to take its place.

Thoughts?

Thanks,
Dan

Changed in evergreen:
assignee: nobody → Dan Wells (dbw2)
Ben Shum (bshum) wrote :

We like it; our preliminary tests don't show any odd quirks so far. Putting this into a test staff client package to roll out to some of our libraries to see how it performs in the field. This has been one of the top irritations reported about 2.0 in our consortium, so the return of the close button in some shape/form should prove quite positive.

Will report back any issues encountered.

Changed in evergreen:
milestone: none → 2.0.4
Ben Shum (bshum) on 2011-03-20
Changed in evergreen:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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