You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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
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.
The text was updated successfully, but these errors were encountered:
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
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:
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
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.
The text was updated successfully, but these errors were encountered: