On Tue, Aug 04, 2015 at 04:50:37PM +0530, Anand Chitipothu wrote:
> That is not really a popup in the traditional sense. The server is setting
> a content-disposition header on the response to force the browser to open a
> file-save dialog. This is not blocked by firefox/chrome.
When I tell Firefox to allow pop-ups, the dialog appears, and when I
tell it to not allow pop-ups, the dialog does not appear and the book
doesn't get checked out. Whether it's a pop-up in the traditional sense
or not, the browser pop-up setting determines whether or not the
checkout succeeds. I wish I could figure out if there's a corresponding
setting in Chromium.
> The open issue is that the webpage will not be aware when the file-save
> dialog is opened. Since OL wants to display a different screen after the
> file is saved, it tired to solve that problem by adding a reload after a
> timeout and that is what creating the trouble.
From my perspective it would be a big improvement to just have the
checkout link download the .acsm file. There are more than enough
browser controls on where and how downloads are stored / opened already,
without OL needing to try and force a save dialog into the process.
Presumably with some JS cleverness it could also change an element in
the page for the edition being viewed to reflect the changed status.
But what it's doing now is, without fail, taking me off to an
entirely different page - one which doesn't even include the site nav
elements - solely to tell me that it *didn't* do exactly what I just
asked it to do. Then I click the link on that page to get it to do what
it should have done in the first place - fetch the .acsm file. Not a
good UI experience.
Jon
_______________________________________________
Ol-discuss mailing list - [email protected]
http://mail.archive.org/cgi-bin/mailman/listinfo/ol-discuss
Archives: http://www.mail-archive.com/[email protected]/
To unsubscribe from this mailing list, send email to
[email protected]
