Re: Proposed W3C Charter: Pointer Events Working Group
I think that Mozilla should comment in favor of the PEWG charter. Mozilla has been participating in the WG and it is doing important work for interop and performance of pointer input handling. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Enabling Pointer Events in Firefox (desktop) Nightly
tl;dr: We plan to enable Pointer Events for mouse and pen input in Firefox Nightly builds within the next few weeks. Background: Pointer Events is a W3C recommendation that defines new DOM events for unified handling of mouse, touch, and pen input. It also defines a new 'touch-action' CSS property for declarative control over touch panning and zooming behavior: http://www.w3.org/TR/pointerevents/ The 'touch-action' CSS property is shipping today in both IE11 and Chrome stable. The DOM PointerEvent API is shipping today in IE11, and the Chrome team plans to ship it soon. Status: Implementation of pointer events and 'touch-action' in Gecko has been in progress for several months. Both features can be enabled in Firefox Nightly with prefs, currently off by default. When these prefs are turned on: * Events for mouse input are supported on Windows, Mac, and Linux. * Events for pen input are supported on Windows. * Events for multi-touch input, and the 'touch-action property, are a work in progress on Windows. These features depend on e10s, and on Async Pan/Zoom (APZ) which is currently preffed off by default on desktop. * PointerEvent and 'touch-action' are not yet implemented on Android or Firefox OS, though in the long term much of the code will be shared between all platforms, through the APZ controller. Plans: The implementation of Pointer Events should be complete enough to enable in desktop Nightly builds within the next few weeks. This will enable Pointer Events for mouse and pen input. (It will also enable Pointer Events for multi-touch input on Windows when e10s and APZ are enabled, though like APZ itself this is still experimental and will not yet be turned on by default.) If no serious problems are found, then we want to consider letting this feature ride the train to the Aurora/Dev.Edition channel (but not further). For the release and beta channels, we may want to wait until after touch input is ready to ship on Windows (depends on e10s + APZ), and we might also want to wait until it is ready to ship on Android and/or Firefox OS at the same time or soon after. When the time is closer, we will send an Intent to Ship email to this list for discussion. See also: This wiki page has some links to tracking bugs and other information: https://wiki.mozilla.org/Gecko/Touch ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Plug-in feature not available in the web platform. Alternatives?
On 11/8/2013 1:33 AM, fma spew wrote: 3- We haven't found any indication of Mozilla about alternatives for these kind of plug-ins, meaning plug-ins that need access to, in this case, Windows stuff. Google has provided alternatives though. One alternative is a Firefox extension. Firefox extensions can access both native platform APIs and web content. In particular, extensions can use js-ctypes to call C/C++ code. We've also mentioned the possibility of bundling a traditional plugin with a Firefox extension to change the default click-to-play behavior: If a plugin is installed bundled within a Firefox extension, the extention can enable the plugin by default (for all sites or for particular sites) via preferences/permissions. Because the user chose to install the addon, I see no problem with allowing this sort of default activating. -- https://mail.mozilla.org/pipermail/firefox-dev/2013-September/000903.html ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cost of ICU data
On 10/17/2013 10:24 AM, Ehsan Akhgari wrote: We used to have codesighs measurements (and perhaps still do) but historically many people just ignored them. We stopped collecting codesighs measurements in November 2012 (bug 803736). As Ehsan says, it was widely ignored. It regressed constantly, and it never seemed reasonable to demand that people implement desired features and fixes without adding any code. For this reason, I'm a bit confused at the level of scrutiny of ICU's size when we've added many times that amount to our download size over the past couple of years without any pushback or even discussion. (On a related note, what happened to http://www.arewesmallyet.com/?) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: devolution of cleartype rendering in Fx chrome
On 10/15/2013 1:36 PM, al...@yahoo.com wrote: Why are these ignored? I can't speak for anyone else, but I would guess it's because no one who has looked at them has figured out any useful information to add, or found the time to investigate further. As to whether we should pull someone off of other tasks to focus on these XP text-rendering bugs, that's tricky. They are user-visible regressions and a large portion of our users are on XP. On the other hand, they do not affect web content; XP is a (slowly) shrinking platform; and the difference between grayscale and subpixel AA is jarring to some users but subtle or invisible to others. In general, if I understand correctly, it's hard to use native subpixel AA in layers that use hardware accelerated compositing. So in some cases we might need to choose between speed and subpixel rendering. (I'm not at all an expert in this area, though.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: devolution of cleartype rendering in Fx chrome
On 10/16/2013 1:24 PM, Karl Tomlinson wrote: Many people use browsers for reading text, so I would like to claim that text rendering quality is usually more important than performance. I apologize for not looking through the referenced bugs. To repeat a point from my previous message: These bugs do not affect rendering of text on web pages. They are about rendering of specific items in the Firefox chrome. (That doesn't mean we should ignore the bugs; I'm just addressing the people use browsers for reading comment above.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal: Email individual patch authors who improve performance
On 2013-08-12 6:14 PM, Matt Brubeck wrote: I've posted a patch that would change how the graph server sends email when a performance *improvement* is detected: https://bugzilla.mozilla.org/show_bug.cgi?id=904250 I landed this patch, and it will go live with the next graph server deployment. I also just landed some patches that should reduce the main causes of false alarms (bug 904322, bug 879903) to minimize any noise/spam from this change. On 8/16/2013 11:27 AM, Mike Hoye wrote: Can other addresses be CC'ed when this specifically (and in the future, other automatically-detectable improvements) are accomplished? I'd like to be able to automate badge-assignment stuff on Mozillians as much as possible, and this would be a big help. Yes -- you can either subscribe your address to the dev-tree-management mailing list to receive all of the emails, or you could add additional logic to the emailWarning function in this code: http://hg.mozilla.org/graphs/file/tip/server/analysis/analyze_talos.py If you want to do the latter, please file a bug in the Release Engineering: Tools component in Bugzilla. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal: Email individual patch authors who improve performance
On 8/13/2013 1:57 PM, Jet Villegas wrote: This is awesome! Is it possible to see a log of the recipients/patches? Yes - all of the emails for both regressions and improvements are also sent to the dev-tree-management list, which is archived at https://groups.google.com/forum/#!forum/mozilla.dev.tree-management ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Embracing git usage for Firefox/Gecko development?
On 5/30/2013 5:56 PM, Johnny Stenback wrote: Some of the known issues with embracing git are: * Performance of git on windows is sub-optimal (we're already working on it). This has become a bit of an urban legend; I often see it repeated but seldom with actual measurements. I don't think it's a valid reason to avoid git unless there are specific cases where git's performance on Windows is insufficient compared to hg's performance on Windows. In some brief tests using hg.mozilla.org/mozilla-central versus github.com/mozilla/mozilla-central on a modern Core i7 laptop with SSD and 8GB RAM, after throwing away the first result (so I'm measuring warm cache times; cold times would be useful too but would take more work for me to measure correctly): log the last 10,000 changes: git 0.745s hg 2.570s blame mobile/android/chrome/content/browser.xul: git 1.015s hg 0.830s diff with no changes: git 2.136s hg 2.001s status: git 3.011s hg 1.680s commit one-line change to configure.in: git 2.420s hg 3.911s clone from remote: git 26m43s hg 19m01s pull from remote to an up-to-date clone: git 1.585s hg 0.875s update working dir from tip to FIREFOX_AURORA_23_BASE: git 16.008s hg 25.704s There *are* some cases where git is worse than hg on Windows, but hg is as bad or worse for many common operations like log, diff, and commit. Overall I find both painful on Windows, but neither noticeably better than the other. (And of course some of these tests are highly unfair because the git repo has a more complete history than the hg one, or because they test network or server performance that is unpredictable and may vary between github and hg.m.o.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Windows XP virtual memory peak appears to be causing talos timeout errors for dromaeo_css
On 6/3/2013 7:28 AM, jmaher wrote: We have a top orange factor failure which is a talos timeout that only happens on windows XP and predominately on the dromaeo_css test. What happens is we appear to complete the test just fine, but the poller we have on the process used to manage firefox never indicates we have finished. After doing some screenshots and looking at the process list, I haven't found much except that on the failing cases the _Total value for Virtual Bytes Peak is 2GB, and for all the passing instances it is ~1.25GB. Are there other things I should look for, or things I could change to fix this problem? This *might* be related to bug 859955 which a few people have been actively working on recently: https://bugzilla.mozilla.org/show_bug.cgi?id=859955 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Embracing git usage for Firefox/Gecko development?
On 5/31/2013 12:32 PM, Boris Zbarsky wrote: On 5/31/13 3:20 PM, Matt Brubeck wrote: blame mobile/android/chrome/content/browser.xul: git 1.015s hg 0.830s Was this a git blame -C (which would be more similar to hg blame), or just a git blame? Good catch. (Sorry, I missed your messages on IRC warning me about this.) The above numbers were without -C. git blame -C takes about 3.7 seconds on this file. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Sandboxed, off-screen pages for thumbnail capture
On 6/17/2013 9:48 PM, Drew Willcoxon wrote: The desktop Firefox team is building a new Toolkit module that captures thumbnails of off-screen web pages. Critically, we want to avoid capturing any data in these thumbnails that could identify the user. More generally, we're looking for a way to visit pages in a sandboxed manner that does not interact with the user's normal browsing session. Does anyone know of such a way or know how we might change Gecko to support something like that? What about launching/forking a separate process to capture thumbnails for these pages? I don't mean an Electrolysis-style child process that is tightly coupled to the browser, but rather a separate program that does not use the Firefox profile at all. The browser would pass this program a URL and it would just render a page and save the thumbnail. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal for an inbound2 branch
On 5/2/2013 6:21 AM, Ehsan Akhgari wrote: On 2013-05-02 5:46 AM, Neil wrote: Why do we need a separate repo? Can we not simply close the broken head and start again at the last green changeset? Multiheaded repos are evil. They're very hard to deal with, and I don't think that buildbot can deal with them properly. Buildbot can deal with a multi-headed Try, so it can probably be convinced to deal with a multi-headed inbound, even if it needs to be a special case like Try. Individual developers might have more problems (they'll want to pull from inbound, unlike Try) but I think as long as the inactive heads are closed it won't freak out Mercurial too much... The suggested workflow with inbound2 would lead to almost-identical multi-headed repos in developers' local clones anyway. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: multiline pref value strings in user.js
On 4/27/2013 3:26 PM, al...@yahoo.com wrote: ... appear to be possible without the \ escape. In fact the \ can not be present as it does not escape the newline but becomes a part of the string. So it does not seem to follow js rules, so what is this format? The format doesn't have a name that I know of; it's that weird format that prefread.cpp parses and it's not really documented except: http://mxr.mozilla.org/mozilla-central/source/modules/libpref/src/prefread.cpp#151 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Improving Mac OS X 10.6 test wait times by reducing 10.7 load
On 4/26/2013 9:10 AM, Armen Zambrano G. wrote: Just disabling debug and talos jobs for 10.7 should reduce more than 50% of the load on 10.7. That might be sufficient for now. I'd be happy for us to disable all Talos jobs on 10.7, on all trees. I've been keeping track of Talos stuff recently and I have not seen any genuine regressions that are 10.7-specific, so I don't think it's providing us much benefit to run these benchmarks on three Mac platforms simultaneously. In terms of tracking regressions, it would be better to have more complete data 10.6 alone than to have incomplete data (due to coalescing) on 10.6 and 10.7. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Experimental Technology in Gecko (Re: Storage in Gecko)
On 4/26/2013 11:43 AM, Gregory Szorc wrote: Have you explored using IndexedDB? Not seriously. The this is an experimental technology warning on MDN is off-putting. The largest audience for MDN is web developers, so we put that warning on anything that's not ready for widespread use on the public web, including most things that are prefixed in current browsers. Here are some other things with the same experimental technology warning on their MDN pages: * JavaScript for...of loops * CSS transform, transition, animation * WebSocket * Set, Map, WeakMap Obviously we have no qualms against using these ourselves. When an experimental technology is one that *we* are promoting as part of the development platform *we* are building, then of course we should using it in our own code. In fact we should be early adopters, because if there are issues that prevent us from using our own APIs, then they will often affect other developers on our platform, so we need to know about those and fix them. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal for an inbound2 branch
On 4/26/2013 4:14 PM, Justin Lebar wrote: If I have a patch ready to land when inbound closes, what would be the sequence of steps that I need to do to land it on inbound2? Would I need to have an up-to-date inbound2 clone and transplant the patch across? I think mbrubeck or someone knows how to maintain multiple hg branches in one repo, but I've never figured that out... Yes, having been a git user for years before I started with Mercurial, I simply treat Mercurial as a slightly crippled version of git. :) hg clone https://hg.mozilla.org/mozilla-central/ cd mozilla-central # hack on some stuff # do some builds and tests hg new my-patch # time to push to inbound: hg qpop hg pull https://hg.mozilla.org/integration/mozilla-inbound/ hg up -c hg qpush hg qfin my-patch hg push -r tip https://hg.mozilla.org/integration/mozilla-inbound/ # Now, let's backport something to Aurora! hg pull https://hg.mozilla.org/releases/mozilla-aurora/ hg export -r a3c55bdbe37d | hg qimport -P -n patch-to-uplift hg push -r tip https://hg.mozilla.org/releases/mozilla-aurora/ # After a good night's sleep, back to work! # hg pull -u won't work across branches, so: hg pull https://hg.mozilla.org/mozilla-central/ hg up -c # do a build # start hacking again! This sort of workflow is of course much more natural in git, which makes it easy to track the state of the remote repo(s). The bookmark workflow that gps added to MDN basically emulates part of the functionality of git remote tracking branches. I'm actually astounded that Mercurial doesn't have better support for this built in; I see Mozilla developers doing crazy time-consuming things all the time because of Mercurial's poor support for working with remote repositories. :( ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Preparing for the next windows PGO build memory exhaustion
On 4/17/2013 3:07 PM, Matt Brubeck wrote: analyze_talos.py does identify several real regressions in that dataset -- but it suppresses emails for them because each one is an increase of less than 2% (see bug 822249). Here are regressions identified by the latest version of analyze.py: In case anyone wants to investigate these, I've added regression ranges below. These are automatically generated; I haven't double-checked them manually. Since we run PGO builds only a few times a day, the ranges can be large. For those that include m-c merges, you could narrow them down using the m-c data. WebIDL seems to be a common theme. changesetmem (KB) t-test % change c1ee454506f6 329686 139.519 1.05% http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=88543d623c3ftochange=c1ee454506f6 (Includes several Paris bindings changes, among others) 0acac77dd920 333029 11.809 0.99% http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=16ddbb6852ectochange=0acac77dd920 (More Paris binding changes, and others) e6ca584f4fe7 335801 9.753 0.86% http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a69f329fc7eetochange=e6ca584f4fe7 (includes the Win8 Metro merge) 80d52655c8b8 339830 74.742 0.45% http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=4637a1449900tochange=80d52655c8b8 (includes some WebIDL-related changes) d27445d1eac5 345040 26.214 0.99% http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=92824d900e25tochange=d27445d1eac5 eaff15332579 346897 70.525 0.52% http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e38c5c346840tochange=eaff15332579 (Olli Pettay — Bug 822399 - Make Event to use Paris bindings) Perhaps we should modify bug 822249 to ignore the 2% threshold for specific tests where we *do* care about small changes. Or for any change with a very high t-test score. I filed this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=863061 A fix has been checked in, so we should start getting alerts for future linker memory regressions of any size. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Preparing for the next windows PGO build memory exhaustion
On 4/18/2013 12:10 PM, Matt Brubeck wrote: Since we run PGO builds only a few times a day, the ranges can be large. For those that include m-c merges, you could narrow them down using the m-c data. WebIDL seems to be a common theme. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=863492 to investigate whether Paris bindings are a particular contributor to linker memory usage, and possible solutions. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: A new way to run mach
On 4/15/2013 11:04 AM, Rob Campbell wrote: On Mac, does mach do the right thing when you rebuild browser, does it also rebuild browser/app so your application bundle gets updated? mach build browser is the same as make -C $objdir/browser (literally, it just executes that make command to do all the work), so just like make it should rebuild all of the sub-directories too as long as the dependencies are correct. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Landing on Trunk - Target Milestone vs. Status Flag Usage vs. Tracking for Future Releases
On 4/10/2013 5:14 PM, Gregory Szorc wrote: I don't really have much to say on the specifics of this post other than a simple question: why don't we have a checkin hook or bot automatically update Bugzilla flags when changesets are pushed? This would save developer time and would reduce the error rate of bugs not updated properly (especially when you consider that policies change over time). http://www.graememcc.co.uk/m-cmerge/ is a tool that will automatically resolve bugs and set Target Milestone correctly for patches pushed to m-c. It's used by most of the people who regularly merge from inbound and other branches to m-c. It still needs to be invoked explicitly by the person who lands/merges the patches, so it's not a fool-proof automatic solution. Just pointing it out for anyone following who doesn't know about this part of the process. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
A new way to run mach
I recently landed a new feature for the mach build tool [1]. You can now run mach from anywhere in the mozilla source tree. To get started, add mach to your $PATH. You can do this by changing the PATH environment variable to include the mozilla source directory, or by copying the mach script from your source directory to a location like /usr/local/bin. Then you can run mach commands from anywhere in your source directory, and you can use paths within your current directory. For example, if you are working on some devtools code you might run commands like: cd browser/devtools # Rebuild the code in browser/devtools/webconsole: mach build webconsole # Run browser-chrome tests from browser/devtools/webconsole/test: mach mochitest-browser webconsole/test # Most commands work the same no matter where you run them: mach clobber mach build # Do a full rebuild mach package mach install You can also run mach within an objdir. If you have multiple objdirs with different mozconfigs, mach automatically defaults to the mozconfig that built the current objdir. This means you can switch between configurations as easily as: cd obj-debug mach build mach xpcshell-test cd ../obj-optimized mach build mach xpcshell-test (Note: the automatically-detected mozconfig is used as a default, but you can still override it by explicitly setting the MOZCONFIG environment variable.) The mach script is now just a wrapper; it loads the actual mach code and configuration from whichever source directory you run it in. So you can add mach to your path once and it should work with any current or future mozilla-central directory. (For older trees, like the current aurora or beta repos, you still need to run mach the old way, using ./mach in the top source directory.) For development details, please see bugs 840588 and 840690 (but note that the feature changed a bit since those bugs were first filed). Huge thanks to gps and all the other people who helped in the design and implementation of this feature! [1] https://developer.mozilla.org/en-US/docs/Developer_Guide/mach [2] https://bugzilla.mozilla.org/show_bug.cgi?id=840588 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=840690 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
setTimeout without a DOM window using Timer.jsm
I noticed a number of places in Mozilla code where setTimeout-like functionality is needed, but DOM window.setTimeout is not available because the code runs in a non-DOM context like a JSM. In a few places we had created pure-JS implementations of window.setTimeout to solve this problem. With Gavin's encouragement, I extracted one of these into a standalone JSM file, to make it easier to share. If you need to call setTimeout without a DOM window, you can now use Timer.jsm: https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modules/Timer.jsm This offers two main benefits over just using nsITimer directly: it makes it easier to re-use code written for use in a DOM window, and it addresses this common nsITimer garbage collection problem: http://www.joshmatthews.net/blog/2011/03/nsitimer-anti-pattern/ For more details, see bug 840360. Thank you to Chris Jones who wrote the original code, and to several other people who gave feedback on it. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming separation between resource://app and resource://gre
On 2/7/2013 6:12 AM, Mike Hommey wrote: - But really, what does it change for developers? Almost nothing they shouldn't be doing already. The main difference is that resource://app/ and resource://gre/ urls are not going to point to the same location anymore, which means I won't have to file bugs about $randomFile including resource://gre/modules/something.jsm instead of resource://app/modules/something.jsm. This seems like a major add-on compatibility issue. Has anyone looked into how many add-ons will now have incorrect resource: URIs? How can we scan for these, and how can we mitigate the breakage? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: UA string: Touch or Tablet again
Here is my personal suggestion for how we should handle this in our Metro browser, and the reasoning behind my proposal. This is meant to be a minimal step to bring Firefox for Metro in line with other platforms, without making changes to any other products. It might need to be tweaked if we make any broader, cross-platform UA changes. This was originally posted at: https://bugzilla.mozilla.org/show_bug.cgi?id=809396#c5 ASSUMPTIONS: A. The UA header is used mainly by sites that serve very different content to different devices. Sites that use the same basic UI for both mouse and touch can serve a single page that works with both types of input and uses feature detection to determine browser capabilities as needed. B. For any site that serves different content to desktop and mobile users, some portion of users will disagree with the site's default (no matter which is the default) and will want to switch to the other version. C. Users of touch-screen devices will sometimes interact with the device primarily through touch, and sometimes interact primarily with a mouse / trackpad / other precise pointer device. (Some users will stick to one interaction type all the time, while others may switch back and forth even on the same device.) D. *Most* people will prefer the touch-friendly Metro Firefox UI while they are interacting primarily through touch, and *most* people will prefer the mouse-friendly desktop Firefox UI while they are interacting primarily with precise pointer devices. E. Many web developers will test on only one or two device types. More variations in the User-Agent header would mean more developers who mishandle some of those variations without realizing it. PROPOSAL: * We should add Tablet to the User-Agent header when the the Metro Firefox UI is used *and* the hardware supports touch input. * For non-touch hardware, we should make no changes to the User-Agent header. * For the classic (desktop) Firefox UI, we should make no changes to the User-Agent header. PROS: * Users who browse in the mouse-friendly Windows desktop environment will see no changes in content. In particular, users of touch-compatible desktops or notebooks who nonetheless prefer the traditional desktop environment will generally see familiar desktop-style web content. * Users who browse in the touch-friendly Windows Metro environment are likely to get touch-optimized content by default. * Sites are unlikely to serve touch-only content to users without touch hardware. * Users have an easy and (somewhat) intuitive way to choose between the tablet and desktop versions of sites, for example by using Metro Firefox's View in desktop command. * Sites that follow our existing guidelines to send tablet-optimized content to Firefox for Android tablets will not need any changes, and will immediately begin serving tablet-optimized content to Firefox for Metro. CONS: * Tablet is not widely used by other browser vendors. Touch would be consistent with Internet Explorer. * Tablet is kind of misleading since it refers to a specific form factor and is not accurate for all devices where people use our touch UI. Touch might look more right, and be more self-documenting. For example, some authors might wrongly assume Tablet implies a certain screen size. These and many related issues are discussed in much more detail at: https://bugzilla.mozilla.org/show_bug.cgi?id=773355 QUESTIONS: Q. Why Tablet and not Touch? Mainly for consistency with our current UA header, especially on Android. Using both Tablet and Touch would complicate our UA, adding more variations and more chances for authors to make errors. Switching from Tablet to Touch would undo some of our evangelism work over the past year, and would involve a transition where both variations exist, again complicating web development and testing. However, I think this is a reasonable question to discuss in bug 773355, and I believe the rest of this proposal would still make sense if we replaced Tablet with Touch everywhere. Q. What about users who want to use desktop Firefox *and* interact with web pages through touch? Ideally, most web developers would use feature detection instead of UA sniffing, and serve a single page with good support for both touch and mouse interaction, which will work in all browsers. But for sites that do use UA sniffing, the best we can do is help developers choose defaults that work best for the majority of users. Users who dislike the default can easily change it by switching between Metro and desktop Firefox, or by using an add-on or about:config to change the header. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
