Re: Proposal: Remove Linux PGO Testing
On Mon, Nov 12, 2012 at 03:47:32PM -0800, Alex Keybl wrote: > Bug 799295 [1], the driver for this thread, is still an open issue for > FF18 (shipping in 6 weeks). The JS team's recommendation remains to > disable PGO on Linux. According to Taras, the major benefits of PGO on > Linux are for a "starry-eyed-future". Given > > > almost nobody uses Mozilla Firefox builds(and no Firefox disributors > > do pgo), it may not be that bad to hurt startup for a few precious > > Linux users. > > I'd like to suggest that we move forward with disabling PGO on Linux > builds, rather than investigating issues that our users will not see > on their non-PGO builds. If you have a differing opinion, please make > a recommendation to the JS team for how to resolve bug 799295. The > only other recommendation in the bug is to drop dromaeojs talos suite > testing on Linux, which I don't have enough context to comment on. Another recommendation would be to try with a newer gcc. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed policy change: reusability of tests by other browsers
I read newsgroups too little (or perhaps just enough, or too much, depending), sorry for the kind-of-late response here... On 10/10/2012 01:26 AM, ja...@hoppipolla.co.uk wrote: > Do you have a concrete suggestion for how to improve this, in a way that > works cross-browser? Well, the cross-domain part should be solvable using proxy autoconfig. The exact setup of that, and the primal server that would appear to exist for all ports/domains/etc. would have to be something each browser/engine configured when it ran tests. That seems unavoidable. I have suggested using PAC like this to WebKit people in the past; to the best of my knowledge they haven't actually done anything with the idea, just kept using localhost/127.0.0.1 to serve HTTP(S) tests. This is nowhere near enough to do interesting things like testing IDN, or subdomains (I'd be surprised if they don't have anything for testing this now, I haven't tried keeping up with what they do, but they might have something), or others. But it gets you a lot even still. > AIUI (which is not very well, so please correct me if I am wrong), the > Mozilla solution involves running a custom XPCOM-based web server, and thus > is not very portable. That's reasonably accurate, for some definitions of "portable". :-) At the time the web server was introduced I don't believe we had Python as a build requirement, so we couldn't have used some Python-based server (the option most likely to be somehow portable across browsers/engines). That probably could be addressed. It'd require rewriting away from ^headers^ files, which do nothing more than let you set custom headers/status when serving a static file. This probably wouldn't be too hard to do. It'd also require rewriting a bunch of SJS files (effectively CGI scripts). That'd be much harder. I believe some b2g/mobile testing has found the SJS thing to reduce the flexibility of how they run tests, but I don't know the details. Such a rewrite might nonetheless be worth it, especially if tests were more shareable as a result. I know I've written tests and run them against other browsers by spinning up a server, manually tweaking the PAC URL for some other browser, then running the tests there -- and gotten value out of doing so, as a poor-man's reference implementation. Jeff ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed style guide modification: using declarations and nested namespaces
On 11/12/2012 10:44 AM, Robert O'Callahan wrote:
> On Mon, Nov 12, 2012 at 9:37 AM, Zack Weinberg wrote:
>
>> The scenario I'm concerned with is when a .cpp file does 'using namespace
>> A;' and then goes on to define a bunch of its *own* symbols; later someone
>> adds a symbol to namespace A, and gets an unexpected break possibly miles
>> from their own code. I see *avoiding* this phenomenon as the primary
>> *benefit* of namespaces, and it's totally lost if you do 'using namespace'
>> even in .cpp files.
>
> I've never ever seen that happen, though.
It's happening. We're trying to add a mozilla::Range struct to mfbt that would
lightly encapsulate a pointer and a length, providing assertions whenever you
index into it, extract start or end pointers, and so on. It would have been
simple to add, but SpiderMonkey has a js::ion::Range struct already. And as a
semi-convenience we had this in one place:
namespace js { using namespace mozilla; }
SpiderMonkey currently does |using namespace js;| all over the place, though,
so in Ion code there was suddenly an ambiguity between mozilla::Range and
js::ion::Range -- even for code written inside the ion namespace, I believe.
Ordinarily the "innermost" Range would win, but once you start opening
namespaces, that rule goes out the door.
We ended up removing the nested |using| above and making all SpiderMonkey
headers qualify everything with mozilla::. We use few enough things from
mozilla:: so far that we switched to |using mozilla::RangedPtr| and so on in
.cpp files and didn't think twice. The patch itself was pretty big and
annoying, but at least we won't have these issues in the future.
Concerning the DOM nsDocument case, one possible solution might be to refer to
those symbols with a still-qualified but not fully-qualified name. Type
inference code uses types:: without much pain; Ion code uses ion:: (inside the
js namespace) without much pain, either.
For another data point, WebKit's WTF headers include |using WTF::Vector| and
such at the bottom of them, and I have seen grumbling and/or regrets about this
decision, as it's caused issues with name conflicts with some of Google's gtest
framework.
Jeff
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal: Remove Linux PGO Testing
Bug 799295 [1], the driver for this thread, is still an open issue for FF18 (shipping in 6 weeks). The JS team's recommendation remains to disable PGO on Linux. According to Taras, the major benefits of PGO on Linux are for a "starry-eyed-future". Given > almost nobody uses Mozilla Firefox builds(and no Firefox disributors do pgo), > it may not be that bad to hurt startup for a few precious Linux users. I'd like to suggest that we move forward with disabling PGO on Linux builds, rather than investigating issues that our users will not see on their non-PGO builds. If you have a differing opinion, please make a recommendation to the JS team for how to resolve bug 799295. The only other recommendation in the bug is to drop dromaeojs talos suite testing on Linux, which I don't have enough context to comment on. -Alex [1] https://bugzilla.mozilla.org/show_bug.cgi?id=799295 On Oct 12, 2012, at 12:33 PM, Taras Glek wrote: > On 10/11/2012 1:34 PM, Mike Hommey wrote: >> On Thu, Oct 11, 2012 at 02:26:33PM -0400, Rafael Ávila de Espíndola wrote: >>> On 10/11/2012 02:33 AM, Mike Hommey wrote: On Wed, Oct 10, 2012 at 05:57:53PM -0400, Justin Lebar wrote: > By "turning off Linux PGO testing", you really mean "stop making and > distributing Linux PGO builds," right? > > The main reason I'd want Linux PGO is for mobile. On desktop Linux, > most users (I expect) don't run our builds, so it's not a big deal if > they're some percent slower. Many people have made claims about that at several different occasions. Can we once and for all come up with actual data on that? That being said, PGO on Linux is between 5 and 20% improvement on our various talos tests. That's with the version of gcc we currently use, which is 4.5. I'd expect 4.7 to do a better job even, especially if we added lto to the equation (and since we are now building on x86-64 machines, we wouldn't have to worry about memory usage ; link time could be a problem, though). Also note that disabling PGO currently also means disabling the optimizations we do on omni.ja (central directory optimizations and reordering). This is somehow covered by bug 773171. >>> >>> I wouldn't be surprised if most of the pgo benefit is because of bad >>> inline decisions by gcc. If we can narrow the gap by adding >>> MOZ_ALWAYS_INLINE, then maybe we can drop pgo. >> >> A non-unsignificant part of the performance improvements PGO gives come >> from code reordering to improve branch prediction. Presumably, we can >> use NS_LIKELY/NS_UNLIKELY to improve some branches manually. > > Theory: > PGO seems like the only way to balance speed vs size. GCC has the effect of > compiling your hot code with -O3 and cold with -Os. > Sure you can gain similar performance gains by aggressively inlining, but you > are going to pay for that dearly in code size(and subsequently startup speed > and to some degree resident memory usage). > > One of the side-effects of being a large program is that code that frequently > runs together has a good likelyhood of being spread around the binary. This > means large apps need larger caches to stay as fast as smaller apps. PGO > offers a way out of this by letting the compiler group warm code in effect > letting your large feature-laden app run as well as a nimbler more > specialized one. Note I had no data to back this up other than my discussions > with GCC devs. > > Littering code with manual branchprediction + inlining seems like a really > failure-prone unscalable alternative. > > Practice: > In practice GCC PGO only has locality benefits at compilation unit level > which results in the same suboptimal locality when linked. Only when one > throws LTO into the mix is locality handled right. However we have not > checked recently if modern GCC is robust enough for our needs yet. So the > main benefit of PGO atm is faster startup vs -O3 builds. > > Since almost nobody uses Mozilla Firefox builds(and no Firefox disributors do > pgo), it may not be that bad to hurt startup for a few precious Linux users. > > Stary-eyed-future: > We need PGO + LTO to generate smallest-possible-fast code on mobile. > Unfortunately I haven't not heard anything reassuring about ARM PGO/LTO in > GCC. It's still likely to be broken as heck. > > Taras > > PS. Rafael, I'd be very happy to switch to clang if it implemented guided > optimizations. I'd be much more tempted to invest resources in fixing clang > bugs in this area than fixing gcc ones. > > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: UA string: "Touch" or "Tablet" again
On 11/12/12 7:51 AM, Gervase Markham wrote: Can we quickly revisit the question of whether to have one of "Touch" or "Tablet" in our UA string under some circumstances? We need to work out how Windows 8 Metro fits into our plans (bug 787786) N. :/ The UA is such a disaster. I wish we'd just freeze the damn thing already (or as close to as possible). Surely there are other ways to help sites do whatever it is they want to do? Justin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed style guide modification: using declarations and nested namespaces
On 2012-11-12 1:44 PM, Robert O'Callahan wrote: On Mon, Nov 12, 2012 at 9:37 AM, Zack Weinberg wrote: The scenario I'm concerned with is when a .cpp file does 'using namespace A;' and then goes on to define a bunch of its *own* symbols; later someone adds a symbol to namespace A, and gets an unexpected break possibly miles from their own code. I see *avoiding* this phenomenon as the primary *benefit* of namespaces, and it's totally lost if you do 'using namespace' even in .cpp files. I see. Thanks for explaining that. I've never ever seen that happen, though. So I'm reluctant to pay an up-front cost to mitigate a problem whose size is unknown but could be smaller than any other problem we have. (And if it does occur in the future, the problem can still be quite easily fixed then.) OK, fair enough. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: XULRunner on OS X, Why is not supported?
On Nov 8, 3:46 pm, richardson.balca...@gmail.com wrote: > I was just reading the effort of installing "open web apps" locally, I'm > assuming the strategy shift that I'm talking about is that Mozilla is betting > on Firefox as their application framework, that would make sense not to > support Xulrunner anymore. > > I would like to see how could one use the native stuff like platform specific > stuff (Cocoa for example) on this "open web apps". Don't get me wrong I love > Web technologies but an HTML TAB is never going to feel the same as the OS > Native TAB. If by TAB you mean the UI element (and not the soft drink, or something else), then I think it's worth pointing out that, on OS X, the tabs in your Firefox window aren't native. They are XUL stylized to look like native tabs (CSS at https://mxr.mozilla.org/mozilla-central/source/browser/themes/pinstripe/browser.css#2113). There's nothing preventing you from stylizing HTML the same way. Simon ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Migrating mozilla-central builds to the Windows 8 SDK
Hey all, Windows 8 metro browser work continues to progress. Within the next couple of months we would like to finish up the process of merging elm over to mozilla-central so we can turn the metro browser bits on in mc nightlies. However before we can do this we'll need to add the latest Windows 8.0 SDK to our builders and switch to using it on mc. This post serves as notice that we are planning to do this and as a request for any feedback, pro or con on this migration. For testing we currently have builds being generated using VS 2010 and 8.0 SDK on Elm. Thus far we haven't found any issues, although exhaustive testing has not taken place. Key notes - * The 8.0 SDK is available stand-alone from Microsoft's web site for free. * Mozilla central currently builds with the 8.0 SDK without any code changes. The vc2010 startup scripts were recently updated to detect and prefer this SDK if present as well. (A new mozilla-build exe hasn't been released, so you will have to download the new script from the mozilla build repo.) * There is one significant difference between 8.0 and past SDKs - the 8.0 SDK does not include a build runtime so a compatible version of Visual Studio will also need to be installed to use it. * Developers will not be required to upgrade to 8.0, Mozilla products will continue to build with the 7.X SDKs just fine. Firefox will build as well, although you will not be able to build the metro browser bits without upgrading to the 8.0 SDK. * We are not planning to install or migrate to Visual Studio 2012. This was part of the original plan but has since been dropped due to various issues. We probably won't revisit this subject until SP1 is released. If you have an questions or comments please post here or contact me on irc. jimm 8.0 SDK tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=774910 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed style guide modification: using declarations and nested namespaces
On Mon, Nov 12, 2012 at 9:37 AM, Zack Weinberg wrote: > The scenario I'm concerned with is when a .cpp file does 'using namespace > A;' and then goes on to define a bunch of its *own* symbols; later someone > adds a symbol to namespace A, and gets an unexpected break possibly miles > from their own code. I see *avoiding* this phenomenon as the primary > *benefit* of namespaces, and it's totally lost if you do 'using namespace' > even in .cpp files. > I see. Thanks for explaining that. I've never ever seen that happen, though. So I'm reluctant to pay an up-front cost to mitigate a problem whose size is unknown but could be smaller than any other problem we have. (And if it does occur in the future, the problem can still be quite easily fixed then.) Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ 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
Re: UA string: "Touch" or "Tablet" again
As Jim mentioned, we've seen problems with our current browser because, when we turn on touch event interfaces in the browser (i.e. document.createTouchEvent), sites start to assume that this is a touch enabled browser and only a touch enabled browser. i.e. users using a mouse on a touch enabled device suddenly find things stop working. I think the bigger problem is just that sites/webapps/etc need to design for both mouse and touch control. Having these interfaces available should actually make that easier by providing a way to re-dispatch mouse events as touch if wanted. I worry that including tokens like this just extends this problem and encourages sites to design for a single mode of interaction. If we need to write more examples/blog posts/etc talking about this problem and potential solutions, I'm happy to help. i.e. I agree with Jimm for the most part. IMO, we should set up media queries for touch/mouse/pen/whatever-enabled devices and sites that really want to detect device support (but they shouldn't ever do this!) can use media queried css + window.matchMedia if they really want to do this. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: UA string: "Touch" or "Tablet" again
On Mon, Nov 12, 2012 at 8:12 AM, Gervase Markham wrote: > On 12/11/12 16:07, Dirkjan Ochtman wrote: >>> D) Use neither, like Chrome. UA sniffing is evil. Developers should use >>> the >>> presence of a touch API to detect touch capability, and use flexible >>> layout >>> to adapt to whatever screen size the user has. This is Google's approach. >> >> >> Given all the options listed, this one sounds seriously attractive. >> Let the developers use appropriate API's to figure out what kind of >> layout is appropriate, instead of having them on confusing UA tokens. > > > In an ideal world, I'm sure they'd all do that. Question is, will they? > > > Gerv On mobile Chrome leaks the device name in the UA this is the current method of hardware feature detection on the Android stock browser as well. Kevin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
DOM Bindings Meeting - Monday @ 12:30 PM PST
Our weekly DOM bindings meetings continue on Monday November 12th at 12:30 PM PST. Meeting details: * Monday, November 12, 2012, 12:30 PM PST * Conference room 7-N, San Francisco office, 7th floor. * Dial-in Info: - Vidyo room: SFO-7N - In office or soft phone: extension 92 - US/INTL: 650-903-0800 or 650-215-1282 then extension 92 - Toll-free: 800-707-2533 then password 369 - Conference num 95704 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed policy change: reusability of tests by other browsers
On 11/08/2012 01:10 PM, Aryeh Gregor wrote: On Wed, Nov 7, 2012 at 4:13 PM, James Graham wrote: There is an experimental branch with this mode in; it isn't production quality yet. I am still unsure that it's a good idea; in particular I think it encourages people to write multiple tests on the same page in such a way that if one fails the whole suite stops running. This seems very unpleasant to deal with; remember that unlike typical Mozilla tests these will not necessarily all pass in their unmodified form, and that modifying imported tests inline creates a headache when you want to merge changes. In Mochitest, a failed assert doesn't stop execution of the file, so even if fails aren't marked inline, the results are still likely to be useful. An unexpected result just prints out a TEST-UNEXPECTED-PASS or TEST-UNEXPECTED-FAIL line to the console instead of TEST-PASS or TEST-EXPECTED-FAIL, which is then slurped out by various line-based parsing tools and reported as a failure. (Yes, our infrastructure is not so sophisticated.) In testharness.js, a failed assert causes the whole test to fail. This is not very useful if the whole file is one giant test that tests lots of different things. If a failed assert wasn't fatal in this experimental new mode, on the other hand, it would still be pretty useful. I think that would be possible to arrange, but you couldn't do that and retain an invariant on the number of tests run in the face of arbitrary (i.e. not asserts) lines of code failing. This would make it very hard to compare results between runs. If you allowed the file as a whole to have a status you could distinguish between "this file ran without unexpected exceptions" and "this file had an unexpected exception", but it still seems like it would be annoying if, when implementing an API, tests for an unimplemented method caused a single "fail" result rather than detailed information about the parts that passed. I know Mozilla use a system where all the tests in a file should pass, but I don't see how that will work well when you don't control the tests. If you are manually editing every file when you import it, I imagine that updating tests will be so time consuming that it will be tempting not to bother. How do you plan to address this? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: UA string: "Touch" or "Tablet" again
Touch++, again. Same points I said in September. Gerv, do you have an online place that captures the discussion? The reason I ask this is my interest to really understand what is the current assumption nowadays on what UA stands for and the complexities involved in this discussion. Plus I wanted to understand a table about reasoning from other vendors. m On Mon, Nov 12, 2012 at 2:36 PM, wrote: > I don’t see how this information will be of any use in deciding how to > present content, and will likely be used in the wrong way which will break > user experiences. > > We have a related situation with W3C touch event interfaces. Web authors > are using their presence as a way to detect mobile devices with the > assumption that these devices don’t support mouse input. See bug 806805 for > feel for what breaks when we add support (rightfully) for touch input > events in the desktop product. I think it’s possible “Tablet” or “Touch” in > the UA could be abused in the same way. > > The real problem here seems to be a lack of a good way to detect device > capabilities, which can change in real-time while the browser is running. > For example, I have a Samsung Series 7 that has touch, a dock, a mouse, and > a keyboard. Docking the device makes it a desktop, undocking it makes it a > tablet. I’d like web sites to react appropriately to these changes – IMHO > this is something that should be solved via information exposed to content > through js or css, and through better documentation / examples on MDN. > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > -- www.telasocial.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: UA string: "Touch" or "Tablet" again
I don’t see how this information will be of any use in deciding how to present content, and will likely be used in the wrong way which will break user experiences. We have a related situation with W3C touch event interfaces. Web authors are using their presence as a way to detect mobile devices with the assumption that these devices don’t support mouse input. See bug 806805 for feel for what breaks when we add support (rightfully) for touch input events in the desktop product. I think it’s possible “Tablet” or “Touch” in the UA could be abused in the same way. The real problem here seems to be a lack of a good way to detect device capabilities, which can change in real-time while the browser is running. For example, I have a Samsung Series 7 that has touch, a dock, a mouse, and a keyboard. Docking the device makes it a desktop, undocking it makes it a tablet. I’d like web sites to react appropriately to these changes – IMHO this is something that should be solved via information exposed to content through js or css, and through better documentation / examples on MDN. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: UA string: "Touch" or "Tablet" again
On 12/11/12 16:07, Dirkjan Ochtman wrote: A) Use "Touch" to indicate "has a touch-sensitive screen (and is not already marked 'Mobile')". This would lead to us using it on tablets, Windows 8 machines, and any other desktop PC with a touchscreen. It would not be removed if a keyboard was _also_ present. This is Microsoft's approach. If the above is true (Windows RT non-touch interfaces are common) then this seems like a bad option. I.e. if Mozilla was to adopt a "Touch" token in the UA, it would seem most ideal to only use it on hardware that's actually touch-capable. Sorry, yes, in case it's not obvious, I am _not_ suggesting using "Touch" on non-touch-capable machines! (And neither does Microsoft, AIUI.) D) Use neither, like Chrome. UA sniffing is evil. Developers should use the presence of a touch API to detect touch capability, and use flexible layout to adapt to whatever screen size the user has. This is Google's approach. Given all the options listed, this one sounds seriously attractive. Let the developers use appropriate API's to figure out what kind of layout is appropriate, instead of having them on confusing UA tokens. In an ideal world, I'm sure they'd all do that. Question is, will they? Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: UA string: "Touch" or "Tablet" again
On Mon, Nov 12, 2012 at 4:51 PM, Gervase Markham wrote:
> Can we quickly revisit the question of whether to have one of "Touch" or
> "Tablet" in our UA string under some circumstances? We need to work out how
> Windows 8 Metro fits into our plans (bug 787786), plus the new pile of
> touch-enabled laptops and desktops that I see in the glossy ads which come
> with my weekly news magazine. The concern I see is that if we stick with
> "Tablet" and apply it consistently only to tablets, it will be increasingly
> not useful to web developers, and simply be a point of gratuitous confusion
> and incompatibility.
Metro doesn't really imply touch, though, does it? AFAICT, Windows RT
("Metro" is a deprecated term, AIUI) is a very visible part of the
non-touch desktop-level Windows 8 UI.
> Consistent options we could adopt on this question:
>
> A) Use "Touch" to indicate "has a touch-sensitive screen (and is not already
> marked 'Mobile')". This would lead to us using it on tablets, Windows 8
> machines, and any other desktop PC with a touchscreen. It would not be
> removed if a keyboard was _also_ present. This is Microsoft's approach.
If the above is true (Windows RT non-touch interfaces are common) then
this seems like a bad option. I.e. if Mozilla was to adopt a "Touch"
token in the UA, it would seem most ideal to only use it on hardware
that's actually touch-capable.
> B) Use "Tablet" to indicate "has a tablet form-factor (N" or greater, where
> suggested value for N is 7). So Windows 8 machines and other touch-screen
> desktop machines would have the desktop UA. If a tablet acquires a keyboard,
> like the Asus Transformer can, the token would ideally be removed. This is
> our current approach, and (as far as I can see) Opera's.
>
> C) Use "Mobile", like the Kindle and Nook. I think it's unlikely we'd want
> to do this for _all_ tablets, so let's say under a certain size, N", and use
> the desktop UA above that size. This is Amazon's approach.
>
> D) Use neither, like Chrome. UA sniffing is evil. Developers should use the
> presence of a touch API to detect touch capability, and use flexible layout
> to adapt to whatever screen size the user has. This is Google's approach.
Given all the options listed, this one sounds seriously attractive.
Let the developers use appropriate API's to figure out what kind of
layout is appropriate, instead of having them on confusing UA tokens.
> Options I want to avoid:
>
> X) Stick with "Tablet", but find out it ends up meaning "Touch" anyway. If
> you are arguing for sticking with Tablet, are you happy that we won't be
> using it on touchscreen desktops and laptops? Do you think that's what
> developers will expect?
>
> Y) Use both. Ick.
>
> Z) Use Touch on Windows 8, and Tablet everywhere else. This is bound to
> throw people off.
>
> Questions that I think are relevant:
>
> 1) What are web developers expecting? Are people making separate touch-only
> sites? Or separate tablet sites? Or are some people doing each of those?
>
> 2) Given the varied sizes of tablet, is a single "Tablet" token, which must
> inevitably have a size cutoff, actually going to be useful? Touch capability
> is at least binary.
Probably not.
> 3) Given the choice of "mobile or desktop", what sort of experience do we
> think people on tablets should have? Does it depend on size?
I think having it depend on size makes a lot of sense.
But that's just my $0.02,
Dirkjan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
UA string: "Touch" or "Tablet" again
Hi everyone, Can we quickly revisit the question of whether to have one of "Touch" or "Tablet" in our UA string under some circumstances? We need to work out how Windows 8 Metro fits into our plans (bug 787786), plus the new pile of touch-enabled laptops and desktops that I see in the glossy ads which come with my weekly news magazine. The concern I see is that if we stick with "Tablet" and apply it consistently only to tablets, it will be increasingly not useful to web developers, and simply be a point of gratuitous confusion and incompatibility. Points to note: 1) I didn't think very hard when deciding to put "Tablet" in our current tablet UA. I'm happy to admit it may have been a mistake. It hasn't been there long and it's probably still possible to remove it. 2) Market data: * iPad has "iPad" and "Mobile". * Opera uses "Tablet". * The RIM Playbook uses "Tablet". * The Kindle Fire has "Mobile" normally, but not in Silk mode. * The Nook Color in desktop mode has "Mobile". (Custom UA in mobile mode.) * Chrome on the Nexus 7 has neither. * Stock Android browser on Asus Transformer (10") has neither. * Windows Phone 8 has "Touch" and "Mobile" (as "IEMobile"). * Microsoft also uses "Touch" on "any machine with touch-capable hardware", including their Windows 8 tablets. As far as I'm aware, IE 10 on Windows 8 has the same UA in Metro and non-Metro modes. Consistent options we could adopt on this question: A) Use "Touch" to indicate "has a touch-sensitive screen (and is not already marked 'Mobile')". This would lead to us using it on tablets, Windows 8 machines, and any other desktop PC with a touchscreen. It would not be removed if a keyboard was _also_ present. This is Microsoft's approach. B) Use "Tablet" to indicate "has a tablet form-factor (N" or greater, where suggested value for N is 7). So Windows 8 machines and other touch-screen desktop machines would have the desktop UA. If a tablet acquires a keyboard, like the Asus Transformer can, the token would ideally be removed. This is our current approach, and (as far as I can see) Opera's. C) Use "Mobile", like the Kindle and Nook. I think it's unlikely we'd want to do this for _all_ tablets, so let's say under a certain size, N", and use the desktop UA above that size. This is Amazon's approach. D) Use neither, like Chrome. UA sniffing is evil. Developers should use the presence of a touch API to detect touch capability, and use flexible layout to adapt to whatever screen size the user has. This is Google's approach. Options I want to avoid: X) Stick with "Tablet", but find out it ends up meaning "Touch" anyway. If you are arguing for sticking with Tablet, are you happy that we won't be using it on touchscreen desktops and laptops? Do you think that's what developers will expect? Y) Use both. Ick. Z) Use Touch on Windows 8, and Tablet everywhere else. This is bound to throw people off. Questions that I think are relevant: 1) What are web developers expecting? Are people making separate touch-only sites? Or separate tablet sites? Or are some people doing each of those? 2) Given the varied sizes of tablet, is a single "Tablet" token, which must inevitably have a size cutoff, actually going to be useful? Touch capability is at least binary. 3) Given the choice of "mobile or desktop", what sort of experience do we think people on tablets should have? Does it depend on size? Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed style guide modification: using declarations and nested namespaces
On 2012-11-10 12:58 AM, Robert O'Callahan wrote: What exactly is the benefit here? As far as I know, "using namespace A; using namespace B;" where both A and B define Foo doesn't actually cause a compile error unless/until the code actually references "Foo". The scenario I'm concerned with is when a .cpp file does 'using namespace A;' and then goes on to define a bunch of its *own* symbols; later someone adds a symbol to namespace A, and gets an unexpected break possibly miles from their own code. I see *avoiding* this phenomenon as the primary *benefit* of namespaces, and it's totally lost if you do 'using namespace' even in .cpp files. Sort of the same thing as adding DOM properties that then collide with website expandos. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal: Not shipping prefixed APIs on the release channel
On Fri, Nov 9, 2012 at 10:32 PM, Ehsan Akhgari wrote: > Sort of. Well, from time to time we add a new DOM API which breaks a > website because they expect that name to be available as an expando property > or something. Prefixing doesn't fix this problem. It only defers it, which (I think) is worse than finding incompatibilities early on and changing the names in the spec not to collide with what’s already used out there. > But that's not really important, I'm mostly concerned about > the stuff that we will ship in the future. The specific thing that I'm > worried about is Web Audio which is a huge spec and we may not be able to > implement all of it for quite a while for a variety of reasons, and it might > be difficult to decide whether implementing more of it will break existing > users, because, among other things, the spec is also changing. If a spec is actively changing in breaking ways, we shouldn’t ship an implementation to the release channel. OTOH, once an implementation has been shipped to the release channel and Web content depends on in, a reasonable spec editor won’t make breaking changes anymore. So if we agree that breaking changes are still necessary, we shouldn’t ship. If we think we need to ship, we need to tell the spec editor not to make breaking changes anymore. -- 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
Re: Proposal: Not shipping prefixed APIs on the release channel
On Fri, Nov 9, 2012 at 7:38 PM, Neil wrote: > Is there any way we can make it so that the prefixed version doesn't work > unless you attempt (and presumably fail) to detect the unprefixed version? What purpose would the prefix serve in such a scenario? -- 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
Re: Proposed policy change: reusability of tests by other browsers
On Sun, Nov 11, 2012 at 4:21 PM, Neil wrote: > Why not simply verify that the list of actual fails equals the list of > expected fails, and report items that are only in one of the two lists? That would be a bit more robust, yes, and it should be doable without much work. It still wouldn't detect the case where different sets of passing tests are run, such as because a change accidentally disabled a large chunk of tests. The system James seems to be describing would detect that condition too. On the other hand, all our existing mochitests don't detect it and we seem to do fine. (There *are* cases where someone accidentally disabled a bunch of tests and no one noticed. Some months ago I found a number of those when I changed mochitests to fail if the file ran no tests. But that only detects if all tests in the file are disabled, not if only a handful are disabled. Still, it's not a common enough scenario that it's worth spending much effort on, IMO.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
