Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ASYOUWISH on recent versions of FF - solved #14

Open
xthdraft opened this issue Jul 2, 2015 · 1 comment
Open

ASYOUWISH on recent versions of FF - solved #14

xthdraft opened this issue Jul 2, 2015 · 1 comment

Comments

@xthdraft
Copy link

xthdraft commented Jul 2, 2015

Up until FF18, AsYouWish worked ok, but thereafter there have been problems particularly concerning local file i/o.

There are 2 workarounds for this problem. Please note I have tested these solutions only using AYW v0.5.2. But I'm fairly sure that the fixes would apply also to Brett's latest versions. Also, my comments regarding AYW only pertain to file i/o: that is, opening and closing files from a filepicker or directly from a filepath string, reading and writing files, creating new files, renaming files, etc. For testing purposes I'm assuming you will have the necessary code to test these capabilities.

The 2 solutions:

  1. Use FF18 protected from upgrades by giving it its own profile. Load in AYW from its .xpi file. Now you have a standalone version of FF which is unrestricted by FF's privelege restrictions.

Shortcomings to this: you miss out on the enhancements of later versions of FF
Advantages: Put FF18 as a shortcut on desktop and you have a standalone app

  1. Here is the better solution: use portableFirefox which is downloadable from portableapps.com. (Note: I've tested this with v34.05 of portableFF - but confident later versions would also work.)
You download portableFF, and place it in its own folder on your C: drive (or on your USB drive if you prefer).  There is a slight difference in functionality between these 2 scenarios - more of which below.

You load in AYW from its xpi file (Note: I haven't tested by loading in from FF add-on tool. I prefer to save the xpi to disk somewhere, then load in from there.)

Voila! FF+AYW should now work as you would expect it to - unrestricted access to the filesystem using XPCOM API's nsifile etc ---- that is to say after you do a couple of minor tweaks which I'll now explain.

Tweak 1: If you have any code which uses XPCOM's create(0,0) it will produce an empty read-only file. Then all your write calls will fail. To avoid this, make sure you write: create(0,0777)

Note: this problem only occurs when you have portableFF activated from the C:drive. From a usb drive, or from FF18, create(0,0) is ok.

Tweak 2: If you are outputting your file content to a div using multiple columns, -moz-column-fill:auto will not work as expected. The columns will become balanced at the end of long file content, and pagination will go screwy. To fix this, you need to place an extra

element with padding-top set by css to a large amount (eg 1000px) as the last

element inside the div. So make your content div :

blah bah... content big enough to require pagination blah blah....

...

In your css you have .pad {padding-top:1000px;}

Hope that helps.

@xthdraft
Copy link
Author

xthdraft commented Jul 2, 2015

Apparantly github didn't render my entry correctly. The last bit was just to say that for file content to output to a multicolumn div, you need to have a P element with its class set so that the css will give it padding-top of 1000px, and this P element should be the last element inside your output div

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant