CI to automate build of zotero tarball for zotero aport
https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/testing/zotero
794238c23f
- Fixed bug in File.hasInternalHandler() (no access to navigator from XPCOM) - Changed "View Attachment" action to check File.hasInternalHandler() and use window.loadURI() for internally handled files and nsIFile.launch() for external -- this prevents the user from getting a helper app dialog when they try to view external files. I basically had to duplicate most of Mozilla's content detection logic and "guess" whether or not it will be able to handle the file internally, which seems a little silly, but, while I feel there are probably better ways to do various parts of this, what's here seems to do the trick. Let me know if you notice it guessing incorrectly (i.e. you get a helper app dialog rather than having a file just open or it launches a file that should've just been loaded into the window). Also look for text files that should be launched rather than opened, especially XML-based data files, as this is a chance for Scholar to be smarter than Firefox itself--for example, OmniGraffle files, which are actually just XML files, normally open up in Firefox as an XML tree, but Scholar will launch them instead. (I imagine the same will need to be done for OmniOutliner, among other things...) |
||
|---|---|---|
| chrome/chromeFiles | ||
| components | ||
| defaults/preferences | ||
| chrome.manifest | ||
| install.rdf | ||
| license.txt | ||
| schema.sql | ||
| scrapers.sql | ||
| update.rdf | ||