reassigning to Roger. He has a patch. Roger, does your patch allow js to obtain a list of all fonts installed on the system? If it did, i think that would be bad.
Assignee: jst → rbs
From: "Roger B. Sidje" <firstname.lastname@example.org> To: email@example.com I got it working. I added a CanRepresent() function: /* @param aString a Unicode string @return aResult do we have all the glyphs to represent this string */ void CanRepresent(in wstring aString, [retval] out boolean aResult); I am attaching some files for illustration how it works in the JS side...
> Roger, does your patch allow js to > obtain a list of all fonts installed on the system? If it did, i think that > would be bad. Yes, the interface (not my patch) already provides hooks to list the fonts: void EnumerateAllFonts(); void EnumerateFonts() void HaveFontFor(); These are the functions that are currently used in the Prefs -> Fonts dialog. Without these, it wouldn't be possible to implement the facility. Only signed scripts (or chrome:// stuff) can execute these (and my patch). If the script comes from a chrome:// source (which is on the user' side), the patch will execute in silence. If it comes from any other source, users will be prompted with the security dialog asking for permission to peek their configuration. And the script will execute only if a user clicks the "grant" button.
OS: Linux → All
Summary: addIs there a glyph for this character on this system? → add: Is there a glyph for this character on this system?
What does this API you speak of look like?
http://lxr.mozilla.org/seamonkey/source/gfx/idl/nsIFontEnumerator.idl To which I added a CanRepresent() function: /* Return true if installed fonts on the system can represent this string. @param aString a Unicode string @return aResult true if there are all the glyphs to represent this string */ void CanRepresent(in wstring aString, [retval] out boolean aResult);
Ah, ok. Any ideas how we'd best expose this to scripts on web content?
Actually, i wanted this to work from a normal web page. For privacy reasons the list of fonts installed on a system can't be exposed to the world, but presumably it would be ok to indicate whether a character is renderable or not. If CanRepresent created its own font enumerator that would make it safe to expose, wouldn't it?
Maybe the solution to Dawn's problem could be to have the mozilla page contain a signed script that could have access to XPConnect to use the suggested API, would that work for you Dawn? If so we don't need to expose this method to web script.
Of note: the fact that the nsIFontEnumerator (like all other scriptable Mozilla interfaces) is already exposed anyway (via XPConnect). Of note (2): yes if the credits page has a signed script or is placed in the chrome dir so that it is served as chrome:// then the problem is solved.
Actually, it turned out that Mozilla wouldn't execute the sample script if served as "file:" even if I "grant" the privilege (I guess I need to set a pref somewhere for the "file:" url to be secure?). Cc:ing jband and mstoltz for any inputs they might have on this bug. Dawn wants a special JS function, say mozCanRepresent(), that can conveniently be used on any webpage without much fuss despite the fact this special function requires additional security privileges. The implementation on the function involves calling a corresponding C++ function built-in Mozilla.
rbs, accessing xpconnect should work from file: as long as you've called netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect"); in the same scope as the access to xpconnect. That should be all that's necessary if you're coming from file:. If I understand what's going on here, we're not talking about revealing the user's fonts to web scripts, just whether a particular string is displayable. This seems reasonable to me. Instead of using a signed script (that's broken right now), have the object that implements this function implement the nsISecurityCheckedComponent interface as well; that makes it scriptable by web scripts.
Although I implemented methods from nsISecurityCheckedComponent but it still requires to explicitly call netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect"); before it can run (and this is even throwing an exception BTW).
Updating QA contact to Shivakiran Tummala.
QA Contact: desale → stummala
Following the recent font revamps, I have attached what I have now. Troubles with security are still there and they prevent the desired seamless integration with web scripts. Also need a helping hand to see how Linux goes -- this way, only the security aspect will remain to sort out (Dawn, interested to see how the patch goes on your Linux box?).
Component: DOM: Core → DOM: Core & HTML
QA Contact: stummala → general
You need to log in before you can comment on or make changes to this bug.