Proposed changes to autocomplete administrative levels
requestAutocomplete [1], for those unfamiliar with the API, is a proposed addition to the HTML spec where browser vendors show a dialog to users for populating payment and address fields on a page. Payment and address autocomplete profiles can be created by the user, where the user fills in individual fields in a native dialog, much like the fields on a web page. Currently, the autocomplete spec [2] includes only locality and region as administrative levels for postal addresses. According to the long discussion thread at [3], some countries, such as China, have three (and soon four) administrative levels. As a result, there is a whatwg proposal [4] to extend the number of autocomplete administrative levels from two to four. These changes need to be reflected in the requestAutocomplete dialog, which will introduce quite a bit of complexity. If we agree with this proposal: Do we have the resources to build our own database of mappings from countries to their administrative levels for postal addresses? For example, a US localizer would indicate that US addresses require the city and state administrative levels, and a Chinese localizer would indicate that Chinese addresses require a provincial level, a prefectural level, and a county level. In addition to the knowing what administrative levels each country uses, we would also need labels for these country-specific levels. For example, an en-US localizer would need to be able to provide the terms city and state for US addresses; province for Canadian addresses; prefecture, county, and village for Chinese addresses; along with any other terms used by other countries. In short, every localizer would need to be able to translate every other countries' administrative levels. There are existing libraries that can transform tokenized fields to postal-compatible blobs; engineers at Google have referred us to libaddressinput [5]. However, this API seems incomplete. For example, the CN query at [6] lists only city and state as required administrative levels, whereas the comments at [3] suggest that there should be three. If we disagree with this proposal: What alternatives do we have? Given that countries require more than two administrative levels in postal address, it seems our options are limited. We can't simply provide a single blob for an entire address as sites generally require more tokenized information. Thanks, Brian [1] http://www.html5rocks.com/en/tutorials/forms/requestautocomplete/ [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#autofilling-form-controls:-the-autocomplete-attribute [3] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-March/084394.html [4] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25235 [5] https://code.google.com/p/libaddressinput/ [6] http://i18napis.appspot.com/address/data/CN ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: navigator.hardwareConcurrency
On 2014-05-13, 9:01 PM, Rik Cabanier wrote:
On Tue, May 13, 2014 at 3:16 PM, Ehsan Akhgari ehsan.akhg...@gmail.com
mailto:ehsan.akhg...@gmail.com wrote:
...
That is not the point of this attribute. It's just a hint for
the author
so he can tune his application accordingly.
Maybe the application is tuned to use fewer cores, or maybe
more. It all
depends...
The problem is that the API doesn't really make it obvious that
you're not supposed to take the value that the getter returns and
just spawn N workers. IOW, the API encourages the wrong behavior by
design.
That is simply untrue.
I'm assuming that the goal of this API is to allow authors to spawn as
many workers as possible so that they can exhaust all of the cores in
the interest of finishing their computation faster. I have provided
reasons why any thread which is running at a higher priority on the
system busy doing work is going to make this number an over
approximation, I have given you two examples of higher priority threads
that we're currently shipping in Firefox (Chrome Workers and the
MediaStreamGraph thread) and have provided you with experimental
evidence of running Eli's test cases trying to exhaust as many cores as
it can fails to predict the number of cores in these situations. If you
don't find any of this convincing, I'd respectfully ask us to agree to
disagree on this point.
For the sake of argument, let's say you are right. How are things worse
than before?
I don't think we should necessarily try to find a solution that is just
not worse than the status quo, I'm more interested in us implementing a
good solution here (and yes, I'm aware that there is no concrete
proposal out there that is better at this point.)
(Note that I would be very eager to discuss a proposal that
actually
tries to solve that problem.)
You should do that! People have brought this up in the past but no
progress has been made in the last 2 years.
However, if this simple attribute is able to stir people's
emotions, can
you imagine what would happen if you propose something complex? :-)
Sorry, but I have a long list of things on my todo list, and
honestly this one is not nearly close to the top of the list,
because I'm not aware of people asking for this feature very often.
I'm sure there are some people who would like it, but there are
many problems that we are trying to solve here, and this one doesn't
look very high priority.
That's fine but we're coming right back to the start: there is no way
for informed authors to make a decision today.
Yes, absolutely.
The let's build something complex that solves everything proposal
won't be done in a long time. Meanwhile apps can make responsive UI's
and fluid games.
That's I think one fundamental issue we're disagreeing on. I think that
apps can build responsive UIs and fluid games without this today on the Web.
I don't have any other cases where this is done.
That really makes me question the positive feedback from web
developers cited in the original post on this thread. Can you
please point us to places where that feedback is documented?
...
Python:
multiprocessing.cpu_count()
11,295 results
https://github.com/search?q=__multiprocessing.cpu_count%28%__29+extension%3Apytype=Code__ref=advsearchl=
https://github.com/search?q=multiprocessing.cpu_count%28%29+extension%3Apytype=Coderef=advsearchl=
...
Java:
Runtime.getRuntime().__availableProcessors()
23,967 results
https://github.com/search?q=__availableProcessors%28%29+__extension%3Ajavatype=Code__ref=searchresults
https://github.com/search?q=availableProcessors%28%29+extension%3Ajavatype=Coderef=searchresults
...
node.js is also exposing it:
require('os').cpus()
4,851 results
https://github.com/search?q=__require%28%27os%27%29.cpus%28%__29+extension%3Ajstype=Code__ref=searchresults
https://github.com/search?q=require%28%27os%27%29.cpus%28%29+extension%3Ajstype=Coderef=searchresults
I don't view platform parity as a checklist of features, so I really
have no interest in checking this checkbox just so that the Web
platform can be listed in these kinds of lists. Honestly a list of
github hits without more information on what this value is actually
used for etc. is not really that helpful. We're not taking a vote
of popularity here. ;-)
Wait, you stated:
Native apps don't typically run in a VM which provides highly
sophisticated functionality for them.
and
That really makes me question the positive feedback from
web developers cited in the original post on
Re: People building and debugging Firefox on Windows wanted
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Build took 41:02 with these options: ac_add_options --enable-chrome-format=flat ac_add_options --disable-optimize ac_add_options --enable-debug-symbols ac_add_options --disable-crashreporter ac_add_options --disable-updates ac_add_options --disable-tests ac_add_options --without-intl-api ac_add_options --enable-jemalloc Builds took 37:12, 34:58 with these additional options: mk_add_options export COMPILE_PDB_FLAG= mk_add_options export HOST_PDB_FLAG= mk_add_options export MOZ_DEBUG_FLAGS=-Z7 (removed ac_add_options --enable-debug-symbols) That's a 9.3% - 14.8% improvement [0][1]. I noticed that PDB files were still generated; is that expected or did I miss something in the configuration options? Also, I did run into an issue where WinDbg wasn't able to show me source code for some functions in xul.dll (which normally it should have been able to). I'll keep investigating to see if that was a fluke or if there are some STR I can post here. [0] https://www.wolframalpha.com/input/?i=1+-+%2837+minutes+12+seconds%29+%2F+%2841+minutes+2+seconds%29 [1] https://www.wolframalpha.com/input/?i=%281+-+%2834+minutes+58+seconds%29+%2F+%2841+minutes+2+seconds%29%29 On 4/24/2014 1:14 AM, Mike Hommey wrote: Hi, While working on shared compilation cache for windows, I noticed I could get a 20% build time improvement with the following in .mozconfig: mk_add_options export COMPILE_PDB_FLAG= mk_add_options export HOST_PDB_FLAG= mk_add_options export MOZ_DEBUG_FLAGS=-Z7 (the downside is a 40% disk space increase of the objdir) This is what is currently used on try, and as far as testing goes, it is good enough for breakpad symbols to have the right data so that crashes in tests can be handled correctly. I'm looking for people to test this setup more thoroughly and see if it affects their debugging. If that works out well, we may make it the default. Cheers, Mike PS: please report what build time difference that makes for you, too. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTdA5fAAoJENMT71e+7HCHlmAQAIKWzlGdUBe/8ZGZN4GgpQI5 IM4Iu8ZvBx+/ltbg9FWD8qwQaDoDvvn90+N3g1d6GL6c9qofkzXAhGJT4rQBdmSo Ky2KxXHwP+20oLufE2zCKVL/w5CYg4sw0E8dsbTAp6A90ZmO72T89wa0S132b9IP 2T4xbJVFND8hecMjQi2eWnqpSEmhg2EXpVw0r4C3LDsCdcUswgV6YdYpcVqjWD2u +JIQvYTSHxxdeF/iMQFU2lA10Bm81Q1w5wHJHSFXpRDtrrDtiu6w8qNqsZ0Ti2AG JMge5Pbb0BJEF/N0lCSQjK4gGnuFda/h6ChbMIspnBJ3C5FIHlOcCOcSob85tyRC A2NdElM6kKOQxODg6dSpZNkJ8GFfUSypl31u4EfuRiIAdeRbz8Y20HjsRMzLc0n+ QHlVVrrnh5fQb9sNDdjwZf5Qs4tDMXgpWedCcWKneLarp5oibh+l8goxsAC2cYVa byGAgUtZUqtKqBYITtakAvVlBjgjJpnHs32E/3P56aHNiWTfcsZ1jvbtom1aZiAj 2GynunSIK5MNZ2YKJ6c/cKdQ6sCd/mpWlb0mzMm8fIJgNfqU8TRpg+F9IE1tr15M JbyQSmxqXW4Ds6KuSvxbO8QdN5lf5SLjaS24wMiihyoZknZfe/K2ijnwsM+DWazm 9mkRag+fABzCJvmW8sDV =Hrww -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: People building and debugging Firefox on Windows wanted
On Wed, May 14, 2014 at 05:46:23PM -0700, Tim Abraldes wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Build took 41:02 with these options: ac_add_options --enable-chrome-format=flat ac_add_options --disable-optimize ac_add_options --enable-debug-symbols ac_add_options --disable-crashreporter ac_add_options --disable-updates ac_add_options --disable-tests ac_add_options --without-intl-api ac_add_options --enable-jemalloc Builds took 37:12, 34:58 with these additional options: mk_add_options export COMPILE_PDB_FLAG= mk_add_options export HOST_PDB_FLAG= mk_add_options export MOZ_DEBUG_FLAGS=-Z7 (removed ac_add_options --enable-debug-symbols) That's a 9.3% - 14.8% improvement [0][1]. I noticed that PDB files were still generated; is that expected or did I miss something in the configuration options? Depends which specific pdb files. The linker still emits pdb files for dlls and executables. There shouldn't be pdb files for objects. Also, I did run into an issue where WinDbg wasn't able to show me source code for some functions in xul.dll (which normally it should have been able to). I'll keep investigating to see if that was a fluke or if there are some STR I can post here. Thanks Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
