Review of changes to Web compat-sensitive prefs in localizations
I've been finding and, to a lesser extent, reporting and writing patches for bugs where a localization sets the fallback encoding to a value that doesn't suit the purpose of the fallback. In some cases, there such bogosity in the intl.properties file (e.g. translation of the word windows as part of a charset label) that I suspect that changes to intl.properties have been landing without review. I propose we adopt a rule that says that localizations need review from the HTML parser module owner (i.e. me) to change the values of preferences that modify the behavior of the HTML parser. (In practice, this means the localizable properties intl.charset.default and intl.charset.detector.) Opinions? -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Accessing @mozilla.org/xmlextras/xmlhttprequest;1 from content
I have an extension that loads an HTML file into a hidden browser and runs
script in the context of the hidden browser window. That script needs to be
able to make crossdomain XHR requests to chrome:// and resource:// URLs that
are apparently now blocked in Firefox 19 (they weren't blocked in Firefox 18).
I'm trying to solve this by injecting my own XMLHttpRequest symbol into the
window that wraps @mozilla.org/xmlextras/xmlhttprequest;1. This means that the
content can instantiate an XHR with chrome privileges and no crossdomain
restrictions. The properties of the XHR object weren't visible in content when
I first tried this, but I solved this using __exposedProps__.
Now I get Permission denied to access property 'documentElement' when
accessing using the responseXML property. I tried setting __exposedProps__ = {
documentElement: r } but this doesn't appear to make a difference (presumably
because setting __exposedProps__ on a native wrapper doesn't work).
Is there a better way to let content do crossdomain XHR? Or is there a good way
to provide a usable XML DOM from chrome to content? I can always reparse
responseText to create my own DOM if there's a way to create a content-friendly
DOM.
Cheers,
Matt
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Accessing @mozilla.org/xmlextras/xmlhttprequest;1 from content
On Fri, Feb 22, 2013 at 7:02 AM, Matthew Gertner matt...@salsitasoft.comwrote: Is there a better way to let content do crossdomain XHR? Or is there a good way to provide a usable XML DOM from chrome to content? I can always reparse responseText to create my own DOM if there's a way to create a content-friendly DOM. You should look at SpecialPowersAPI.createSystemXHR. It's what we use in our test suite to do this. There's also a systemXHR facility built into Gecko for allowing certain sites to do cross-origin XHRs without CORS that's being used for b2g, but I don't think it works to chrome or resource protocols. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Review of changes to Web compat-sensitive prefs in localizations
On 22.02.13 15:37, Henri Sivonen wrote: I've been finding and, to a lesser extent, reporting and writing patches for bugs where a localization sets the fallback encoding to a value that doesn't suit the purpose of the fallback. In some cases, there such bogosity in the intl.properties file (e.g. translation of the word windows as part of a charset label) that I suspect that changes to intl.properties have been landing without review. I propose we adopt a rule that says that localizations need review from the HTML parser module owner (i.e. me) to change the values of preferences that modify the behavior of the HTML parser. (In practice, this means the localizable properties intl.charset.default and intl.charset.detector.) Opinions? I don't think that .platform is the right group to discuss policies for l10n, tbh. Anyway, I don't think that it requires your review. For one, these rules just don't work in practice. We're facing the very same problem with search engines. There's just no other way than post-mortem work. That's one of the reasons why we're not taking arbitrary changesets to ship to any audience beyond aurora and nightly, for beta and release, we got to have technical checks in place. I usually catch regressions to intl.properties when reviewing requests for updates to those changesets. That said, I don't know what intl.charset.detector should be set to, aside from nothing. Looking at your patch, the comment doesn't make that clearer, too, I'll follow up there. Axel ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Review of changes to Web compat-sensitive prefs in localizations
On Feb 22, 2013 5:30 PM, Axel Hecht l...@mozilla.com wrote: There's just no other way than post-mortem work. That's one of the reasons why we're not taking arbitrary changesets to ship to any audience beyond aurora and nightly, for beta and release, we got to have technical checks in place. Where should I file bugs to add checks to this set of checks? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Review of changes to Web compat-sensitive prefs in localizations
On Friday 2013-02-22 16:37 +0200, Henri Sivonen wrote: I've been finding and, to a lesser extent, reporting and writing patches for bugs where a localization sets the fallback encoding to a value that doesn't suit the purpose of the fallback. In some cases, there such bogosity in the intl.properties file (e.g. translation of the word windows as part of a charset label) that I suspect that changes to intl.properties have been landing without review. It might not be a bad idea to have a better explanation in http://mxr.mozilla.org/mozilla-central/source/toolkit/locales/en-US/chrome/global/intl.properties of why one would want to change intl.charset.default and intl.charset.detector, explaining clearly that they should only be set to interesting values to deal with a substantial body of legacy content that requires those values, and then saying what they should be in the absence of such legacy content (the latter should clearly be empty; I'm not sure whether the former should be UTF-8 or ISO-8859-1, but we should have a consistent policy). That said, I don't actually know whether the tools localizers use to do localization lead them to read the text. The reality is that I suspect it may be important for you to do occasional audits of these values; it could also be valuable to have a tool that exposes all of them in a single place (perhaps even a place with history, like an automatically-generated wiki page). -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Review of changes to Web compat-sensitive prefs in localizations
On 22.02.13 20:02, L. David Baron wrote: On Friday 2013-02-22 16:37 +0200, Henri Sivonen wrote: I've been finding and, to a lesser extent, reporting and writing patches for bugs where a localization sets the fallback encoding to a value that doesn't suit the purpose of the fallback. In some cases, there such bogosity in the intl.properties file (e.g. translation of the word windows as part of a charset label) that I suspect that changes to intl.properties have been landing without review. It might not be a bad idea to have a better explanation in http://mxr.mozilla.org/mozilla-central/source/toolkit/locales/en-US/chrome/global/intl.properties of why one would want to change intl.charset.default and intl.charset.detector, explaining clearly that they should only be set to interesting values to deal with a substantial body of legacy content that requires those values, and then saying what they should be in the absence of such legacy content (the latter should clearly be empty; I'm not sure whether the former should be UTF-8 or ISO-8859-1, but we should have a consistent policy). That said, I don't actually know whether the tools localizers use to do localization lead them to read the text. The reality is that I suspect it may be important for you to do occasional audits of these values; it could also be valuable to have a tool that exposes all of them in a single place (perhaps even a place with history, like an automatically-generated wiki page). -David Henri filed https://bugzilla.mozilla.org/show_bug.cgi?id=844042 before posting here (or at least around the same time). Axel ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Accessing @mozilla.org/xmlextras/xmlhttprequest;1 from content
- Original Message - From: Matthew Gertner matt...@salsitasoft.com To: dev-platform@lists.mozilla.org Sent: Friday, February 22, 2013 7:02:40 AM Subject: Accessing @mozilla.org/xmlextras/xmlhttprequest;1 from content I have an extension that loads an HTML file into a hidden browser and runs script in the context of the hidden browser window. That script needs to be able to make crossdomain XHR requests to chrome:// and resource:// URLs that are apparently now blocked in Firefox 19 (they weren't blocked in Firefox 18). I believe that the Addon SDK (a.k.a. JetPack) has special provisions for this; See [1], section Content Scripts. In particular, I think that if you inject a content script into the browser then the content script will be able to make cross-origin requests like you propose. At least, I know that the Addon SDK required an extension to the nsIPrincipal interface to support multi-origin principals for this case. I am particularly interested if this strategy would work for you and other addon developers. Cheers, Brian [1] https://addons.mozilla.org/en-US/developers/docs/sdk/1.12/dev-guide/guides/xul-migration.html ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
LOAD_ANONYMOUS + LOAD_NOCOOKIES
sry for double posting this to dev-apps-firefox. got a hint that this group would be the better group. hi i'm willing to fix https://bugzilla.mozilla.org/show_bug.cgi?id=836602 Summary: The rest api should not send cookies and thus now uses the LOAD_ANONYMOUS flag. But this flag also denies (client side) authentication like my custom firefox sync requires. therefore firefox sync is broken for me since = F18. As suggested by rnewman i'm going to add more fine grain LOAD_ constants. (bug comment #13) i'm planing to add 2 new constants: const unsigned long LOAD_NOCOOKIES = 1 15; .. just stop sending / accepting cookies at this request const unsigned long LOAD_NOAUTH = 1 16; .. don't add authentification headers automatically the second constant would be the fix for https://bugzilla.mozilla.org/show_bug.cgi?id=646686 Maybe i can get some input from the Gecko folks? -Bernhard ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: LOAD_ANONYMOUS + LOAD_NOCOOKIES
bernhardr...@gmail.com wrote: i'm willing to fix https://bugzilla.mozilla.org/show_bug.cgi?id=836602 Summary: The rest api should not send cookies and thus now uses the LOAD_ANONYMOUS flag. But this flag also denies (client side) authentication like my custom firefox sync requires. therefore firefox sync is broken for me since = F18. Which modes of authentication does the Sync team wish to support in the product? Currently it supports and requires (I think) HTTP authentication without cookies and without SSL client certificates. The proposal (I think) is to support SSL client certificates with HTTP authentication. But, if you area already doing SSL client authentication then do you really need HTTP authentication too? Should that mode of operation be, instead, SSL client authentication without HTTP authentication and without cookies? How would the Sync client decide whether to use SSL client certificates or HTTP authentication? Would there be some new UI? I am willing to help with things (e.g. reviewing the tests) but it is up to the Sync team to decide on the prioritization of the work and decide what the testing requirements are. IMO, writing tests for this will be difficult as there's no framework for SSL client cert testing. i'm planing to add 2 new constants: const unsigned long LOAD_NOCOOKIES = 1 15; const unsigned long LOAD_NOAUTH = 1 16; the second constant would be the fix for https://bugzilla.mozilla.org/show_bug.cgi?id=646686 I don't see a problem with adding these. But, we should be clear on what the final goal of this work is. Cheers, Brian ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: LOAD_ANONYMOUS + LOAD_NOCOOKIES
On 2/22/2013 5:41 PM, Brian Smith wrote: bernhardr...@gmail.com wrote: i'm willing to fix https://bugzilla.mozilla.org/show_bug.cgi?id=836602 Summary: The rest api should not send cookies and thus now uses the LOAD_ANONYMOUS flag. But this flag also denies (client side) authentication like my custom firefox sync requires. therefore firefox sync is broken for me since = F18. Which modes of authentication does the Sync team wish to support in the product? Currently it supports and requires (I think) HTTP authentication without cookies and without SSL client certificates. The proposal (I think) is to support SSL client certificates with HTTP authentication. But, if you area already doing SSL client authentication then do you really need HTTP authentication too? Should that mode of operation be, instead, SSL client authentication without HTTP authentication and without cookies? How would the Sync client decide whether to use SSL client certificates or HTTP authentication? Would there be some new UI? I am willing to help with things (e.g. reviewing the tests) but it is up to the Sync team to decide on the prioritization of the work and decide what the testing requirements are. IMO, writing tests for this will be difficult as there's no framework for SSL client cert testing. We'd likely change Sync to statically use LOAD_NOCOOKIES. The important consideration is for cookies to not automatically creep into requests because we don't want to leak details to the Sync server from other parts of the domain (Mozilla's Sync servers would be receiving cookies for mozilla.com!). Sync never uses cookies, so it shouldn't be a problem to blanket disable them. Honestly, Sync should probably offer an API that allows modification of outgoing HTTP requests for non-standard setups. But, that doesn't solve the problem that there are legitimate use cases beyond Sync that want finer control than what LOAD_ANONYMOUS currently provides. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: LOAD_ANONYMOUS + LOAD_NOCOOKIES
On 2/22/13 7:25 PM, bernhardr...@gmail.com wrote: const unsigned long LOAD_NOCOOKIES = 1 15; ... just stop sending / accepting cookies at this request 115 is LOAD_FRESH_CONNECTION, no? const unsigned long LOAD_NOAUTH = 1 16; ... don't add authentification headers automatically 116 is LOAD_DOCUMENT_URI. So at the very least you'll need different values for these constants. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Running mousemove events from the refresh driver
On Feb 21, 2013 3:12 PM, Robert Oapos;Callahan rob...@ocallahan.org wrote: On Wed, Feb 20, 2013 at 9:41 AM, Anthony Jones ajo...@mozilla.com wrote: We really have to choices: A. Provide an API that allows applications to specify whether they are type 1 or type 2. It could be implicitly done by including a mouse event history array. B. Automatically prevent flooding (as per roc's suggestion) C. Both of the above. Option A fixes most cases but adds more complexity to the API (although not much). Poorly written applications or slow systems may still end up flooding. Option B will mostly fix the problem but will waste CPU cycles if your application is type 1. We pretty much have to do something automatic, so I think we do B, and then if and when it's worthwhile, A. Well, my proposal was to default all pages to type 1, and only send them mouse events at 60 frames per second. And then let them opt in to being type 2. This should be fine since I strongly suspect that type 1 is the by far more common case and is also what chrome does. In this case just doing A would be enough, no? Though I guess even then we might need to do the anti-flooding thing for websites that opt in to being type 2? / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Notice of browser and toolkit theme renamings
Hi,
I wanted to let you all know about bug 842913, of which I just landed the patch
for on mozilla-inbound.
The goal of the bug is to make the process of working with the /browser and
/toolkit themes easier for new contributors. The previous names of
{winstripe,pinstripe,gnomestripe} were never exposed in the product and were
unclear to new users as to which platforms/environments they targeted.
In toolkit:
/toolkit/themes/winstripe/ becomes /toolkit/themes/windows/
/toolkit/themes/pinstripe/ - /toolkit/themes/osx/
/toolkit/themes/gnomestripe/ - /toolkit/themes/linux/
/toolkit/themes/pmstripe/ - /toolkit/themes/os2/
/toolkit/themes/faststripe/ - (unchanged)
In browser:
/browser/themes/winstripe/ becomes /browser/themes/windows/
/browser/themes/pinstripe/ - /browser/themes/osx/
/browser/themes/gnomestripe/ - /browser/themes/linux/
Most of the work to complete the patches is based on |hg rename|, but some
files that reference paths needed to be updated manually. This may affect
SeaMonkey, Thunderbird, and any other toolkit-based applications.
This work builds on top of bug 838244 (shared theme resources for /browser),
and upcoming work in bug 844412 (shared theme resources for /toolkit). These
three bugs should help to make our theme implementations easier and more
intuitive for both experienced and inexperienced contributors.
One issue that is still remaining is the non-obvious way that the linux-toolkit
theme is generated using the windows-toolkit theme as a base. The work in bug
844412 should help to reduce some of this confusion. Overall, there was a
consensus that the net-wins of this rename are worth it even though it doesn't
solve the theme-derivation situation.
Cheers,
Jared
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
