Re: Gecko 17 as the base for B2G v1
On 02/08/2012 06:32 AM, Alex Keybl wrote: Can you clarify this? It sounds like changes would land on aurora *first*, and then be forward-ported to mozilla-central. Which, IMO, goes against the basic principles of how our branches work. Only in the very rare instance where B2G v2 (Gecko changes in 18 and up) has diverged too significantly to easily forward-port a patch, will we land B2G-specific changes on FF17 only. I'm confused by this statement. Would this mean that certain features/fixes only appear in 17? What about B2G v2 (and later)? Won't you *need* to port everything anyhow, unless you want to be stuck on Gecko 17 until the end of days? :-) Which brings me to another question: how long do you expect to keep B2G on Gecko 17? (eg. will v2 be off 17 or off the next ESR or off something else still?) Fragmentation on eg. Android is well-documented, what's the plan in that department? Will/would/could the partial update mechanism (or similar) be used to just upgrade shipped phones to higher Gecko versions? Would those always be ESRs? (I guess only the first question is really directly relevant to this thread, but it seems to me the rest of the questions tie into it) ~ Gijs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Gecko 17 as the base for B2G v1
On 8/2/2012 12:07 AM, Gijs Kruitbosch wrote: Which brings me to another question: how long do you expect to keep B2G on Gecko 17? (eg. will v2 be off 17 or off the next ESR or off something else still?) Fragmentation on eg. Android is well-documented, what's the plan in that department? Fragmentation is something we will eventually need to plan to avoid. I share your concerns. But I don't think this is a problem we have to solve now. We're talking about a first release to a very limited audience. Spinning our wheels worrying about fragmentation today is probably more wasteful and distracting than productive. It's certainly not a critical part of this particular discussion thread. - A ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Gecko 17 as the base for B2G v1
On 01/08/2012 22:47, Alex Keybl wrote: On 10/7, we'll similarly move active B2G v1 platform development to mozilla-beta, and on 11/19 work will move to the mozilla-esr17 branch. A notice referencing this dev.platform post will be sent to the enterprise list shortly for comment, as some of the ESR goals in [1] will need to change slightly. Can you elaborate on the goal changes? The only thing I can see from your enterprise post is the addition of the support of B2G off the next ESR branch. If I'm understanding correctly then there is no intended affect on ESR itself? Thanks Mark. [1] https://wiki.mozilla.org/Enterprise/Firefox/ExtendedSupport:Proposal ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
B2G update expectations (was: Re: Gecko 17 as the base for B2G v1)
On Thu, Aug 2, 2012 at 10:20 AM, Asa Dotzler wrote: > On 8/2/2012 12:07 AM, Gijs Kruitbosch wrote: > >> Which brings me to another question: how long do you expect to keep B2G >> on Gecko 17? (eg. will v2 be off 17 or off the next ESR or off something >> else still?) Fragmentation on eg. Android is well-documented, what's the >> plan in that department? > > Fragmentation is something we will eventually need to plan to avoid. Is there a plan that involves offering eventual Gecko updates OTA to devices that initially shipped with B2G v1 / Gecko 17? > I share > your concerns. But I don't think this is a problem we have to solve now. > We're talking about a first release to a very limited audience. The update plans have relevance to how the first release is perceived, though. (Whether there's an expectation that the device keeps getting better every 6 weeks like Firefox outside Firefox OS has bearing on how desirable a Firefox OS device is as a purchase.) -- 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: PGO and Windows
Zack Weinberg a écrit : Does MS have any plan to support the x32 memory model? It needs kernel as well as compiler support. Could a shim layer possibly bring x32 to a x64 process under Windows ? Or else have most of the code handle memory as "offset inside a bucket", and reduce most pointer to the 32 bits offset. It would be good to precisely measure what slows down 64 bits with side by side performance comparison using hardware performance counters like the one oprofile under Linux has access to, that can count the number of cache miss, branch mis-prediction, and the like. It can give a very precise idea of how efficiently the CPU runs. BTW the last time I had Seamonkey use all the 32-bits adress space, the result was *really* bad. A system down to it's knees, and not able to close the Seamonkey process anymore. It's harder to get the same thing with Firefox, the lazy tab opening helps :-) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
"Touch" or "Tablet"?
http://blogs.msdn.com/b/ie/archive/2012/07/12/ie10-user-agent-string-update.aspx IE10 has introduced the Touch token to the UA string, which overlaps in intent with our Tablet token. Dao suggests it would be nice to get cross-browser consistency here. https://bugzilla.mozilla.org/show_bug.cgi?id=773355 This makes some sense to me. "Touch" is more the matter of interest than the form factor. If we do switch, we should do it before we ship native Fennec on tablets. Anyone want to argue for or against? Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
HTTP-ON-EXAMINE-MERGED-RESPONSE
According to the MDN here: https://developer.mozilla.org/en/Observer_Notifications#HTTP_requests HTTP-ON-EXAMINE-MERGED-RESPONSE is: called *instead* of http-on-examine-response when a response will be read partially from cache, and partially from the network (HTTP 206 or 304 response). Headers are available on the channel. --- But it looks like that HTTP-ON-EXAMINE-MERGED-RESPONSE can be sent *after* http-on-examine-response *and not instead* Could anybody confirm/verify? Thanks! Honza ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: "Touch" or "Tablet"?
On Thu, Aug 02, 2012 at 02:32:30PM +0100, Gervase Markham wrote: > http://blogs.msdn.com/b/ie/archive/2012/07/12/ie10-user-agent-string-update.aspx > > IE10 has introduced the Touch token to the UA string, which overlaps in > intent with our Tablet token. > > Dao suggests it would be nice to get cross-browser consistency here. > https://bugzilla.mozilla.org/show_bug.cgi?id=773355 > > This makes some sense to me. "Touch" is more the matter of interest than > the form factor. If we do switch, we should do it before we ship native > Fennec on tablets. > > Anyone want to argue for or against? My pedantic self would like to argue that Touch isn't a synonym of Tablet. As a matter of fact, smartphones would fit the bill to have Touch in their UA, if you read what the MS blog says strictly. I however do agree that there is a need to distinguish whether the user agent is touch-capable or not, not only for tablets, but also for the increasing number of desktop PCs that come with touch screens. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: "Touch" or "Tablet"?
> http://blogs.msdn.com/b/ie/archive/2012/07/12/ie10-user-agent-string-update.aspx > > IE10 has introduced the Touch token to the UA string, which overlaps > in > intent with our Tablet token. > > Dao suggests it would be nice to get cross-browser consistency here. > https://bugzilla.mozilla.org/show_bug.cgi?id=773355 > > This makes some sense to me. "Touch" is more the matter of interest > than > the form factor. If we do switch, we should do it before we ship > native > Fennec on tablets. > > Anyone want to argue for or against? My argument against is that this change continues the churn on our UAs, which have already been publicized [1]. Unless there is a clear benefit, I think we should avoid shooting ourselves in the foot by making changes that may impact compatibility. However, in all fairness, I have no data on how many sites currently recognize the Firefox Tablet UA. Lawrence [1] https://developer.mozilla.org/en/Gecko_user_agent_string_reference ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: "Touch" or "Tablet"?
On Thursday, August 2, 2012 7:09:43 AM UTC-7, Lawrence Mandel wrote: > > http://blogs.msdn.com/b/ie/archive/2012/07/12/ie10-user-agent-string-update.aspx > > > > > > IE10 has introduced the Touch token to the UA string, which overlaps > > > in > > > intent with our Tablet token. > > > > > > Dao suggests it would be nice to get cross-browser consistency here. > > > https://bugzilla.mozilla.org/show_bug.cgi?id=773355 > > > > > > This makes some sense to me. "Touch" is more the matter of interest > > > than > > > the form factor. If we do switch, we should do it before we ship > > > native > > > Fennec on tablets. > > > > > > Anyone want to argue for or against? > > > > My argument against is that this change continues the churn on our UAs, which > have already been publicized [1]. Unless there is a clear benefit, I think we > should avoid shooting ourselves in the foot by making changes that may impact > compatibility. However, in all fairness, I have no data on how many sites > currently recognize the Firefox Tablet UA. > > > > Lawrence > > > > [1] https://developer.mozilla.org/en/Gecko_user_agent_string_reference I agree with Lawrence. We know we have had a problem with churn on the user agent and partners have complained about it for being one of the reasons why X site stopped working on Firefox for Android. As a point of comparison btw - what does the user agent of Safari on the IPad look like for comparison? IPad is dominant on the tablet market right now, so they might be a good point for comparison. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Switching nsnull to nullptr
On 07/28/2012 05:19 PM, thus spoke Jonas Sicking: > When are we doing PRUint32? ;-) +1! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Disabling tests
Maybe we should take a different approach to the problem... Have an all-developer "fix orange tests" day where developers work ONLY on fixing random oranges (maybe once you've successfully fixed 1 or 2 random oranges, you can go back to your other work?) Not meant as a criticism, but rather just a suggestion - not trying to be rude. ~Scott On Wed 25 Jul 2012 04:34:27 AM CDT, Dao wrote: > On 25.07.2012 02:05, ben turner wrote: >> Disabling a test without a peer's input and then leaving open an >> unassigned bug to re-enable it is a pretty good way to leave the test >> disabled forever. > > Seems like somebody should be watching the component and take care of > the bug. If this doesn't happen, maybe the test wasn't important after > all? > ___ > 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: "Touch" or "Tablet"?
On 08/02/2012 09:32 AM, Gervase Markham wrote: > http://blogs.msdn.com/b/ie/archive/2012/07/12/ie10-user-agent-string-update.aspx > > IE10 has introduced the Touch token to the UA string, which overlaps in > intent with our Tablet token. > > Dao suggests it would be nice to get cross-browser consistency here. > https://bugzilla.mozilla.org/show_bug.cgi?id=773355 > > This makes some sense to me. "Touch" is more the matter of interest than > the form factor. If we do switch, we should do it before we ship native > Fennec on tablets. > > Anyone want to argue for or against? 1. Let's not chase every browser's UA change. UAs _suck_ and I'd rather leave ours alone now that we fought through the debate. 2. "Touch" is way too ambiguous. I have no desire to add "Touch" to our smartphone UA as well - just for completeness. Using "Touch" alone for tablets or desktops with touchscreens is not interesting to me. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: "Touch" or "Tablet"?
I want to just kick a parenthesis here. This thread called my attention because yesterday I just went through the passage "Kinect’s remarkable gestural interface, for example, makes clear that Microsoft no longer insists its customers master multimedia, multiplayer complexity. Microsoft instead asks customers to become people who see their entire body as a user inter- face. Kinect is the kinesthetic antithesis to Windows. As of this writ- ing, the company’s mainstream management isn’t quite sure what to do with it. For example, should Microsoft’s leadership bring that kines- thetic innovator’s ask to the enterprise workplace?" >From Who do You Want Your Customers to Become? Michael Schrage Harvard Business Review Press, Boston, Massachusetts. It seems that this may cause awareness that MSFT shifts from multimedia complexities, or device, to a touch—human aspect as being the actual OS experience. m On Thu, Aug 2, 2012 at 12:59 PM, Mark Finkle wrote: > On 08/02/2012 09:32 AM, Gervase Markham wrote: >> http://blogs.msdn.com/b/ie/archive/2012/07/12/ie10-user-agent-string-update.aspx >> >> IE10 has introduced the Touch token to the UA string, which overlaps in >> intent with our Tablet token. >> >> Dao suggests it would be nice to get cross-browser consistency here. >> https://bugzilla.mozilla.org/show_bug.cgi?id=773355 >> >> This makes some sense to me. "Touch" is more the matter of interest than >> the form factor. If we do switch, we should do it before we ship native >> Fennec on tablets. >> >> Anyone want to argue for or against? > > 1. Let's not chase every browser's UA change. UAs _suck_ and I'd rather > leave ours alone now that we fought through the debate. > > 2. "Touch" is way too ambiguous. I have no desire to add "Touch" to our > smartphone UA as well - just for completeness. Using "Touch" alone for > tablets or desktops with touchscreens is not interesting to me. > ___ > 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: "Touch" or "Tablet"?
On Thursday, August 2, 2012 6:32:30 AM UTC-7, Gervase Markham wrote: > http://blogs.msdn.com/b/ie/archive/2012/07/12/ie10-user-agent-string-update.aspx > > IE10 has introduced the Touch token to the UA string, which overlaps in > intent with our Tablet token. > > Dao suggests it would be nice to get cross-browser consistency here. > https://bugzilla.mozilla.org/show_bug.cgi?id=773355 > > This makes some sense to me. "Touch" is more the matter of interest than > the form factor. If we do switch, we should do it before we ship native > > Fennec on tablets. > > Anyone want to argue for or against? > > Gerv I'm curious why there's a need here? In fact, I think I'd argue that form factor was much more the driving interest behind the entire thing that sparked including "Tablet" in the UA. Mobile wanted the word "Mobile" in the UA on small screen devices and not on tablets in order to differentiate the two. Most sites are still sending completely specialized content to small screen devices. Adapting an estabilished site to a responsive design setup isn't going to be easy for them (nor is it always possible), and they don't want to resort to slow stub page tricks to find out form factor info. "Tablet" was added later when other people became involved (and I argued against it at the time). Touch is a different ball though. Adapting for touch on the fly is (arguably?) much MUCH easier than adapting your sites layout and design for phone vs desktop/tablet. Things sites/we can do to make it better: 1.) Sites can listen for touch events in addition to mouse ones. Its an insignificant bit of extra code, and we should push for jQuery desktop and other widget sets to start supporting touch as well. 2.) We should make sure touch-enabled media selectors are working so that sites can optimize button sizes, layouts, etc. for touch screens if they want. TBH, I haven't seen a strong need for this. Tablets for us are at least 10in devices, and we lay them out at 980px wide by default. With those settings, I've never had trouble with button or link sizes. 3.) We should also provide more reliable script hooks to detect if the device supports touch? Right now I think sites just check for document.createTouch which we turn off on desktop via a pref. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Gecko 17 as the base for B2G v1
For a discussion of current B2G test automation status and future plans, see this blog post: http://jagriffin.wordpress.com/2012/07/31/mozilla-a-team-b2g-test-automation-update/ Jonathan On 8/1/2012 9:30 PM, Boris Zbarsky wrote: On 8/1/12 5:47 PM, Alex Keybl wrote: any desktop/mobile change that negatively impacts B2G builds in a significant way will be backed out (and vice versa). Do we have any sort of B2G test coverage? Ideally on try? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: "Touch" or "Tablet"?
On Thu, Aug 2, 2012 at 12:54 PM, wrote: > On Thursday, August 2, 2012 6:32:30 AM UTC-7, Gervase Markham wrote: >> http://blogs.msdn.com/b/ie/archive/2012/07/12/ie10-user-agent-string-update.aspx >> >> IE10 has introduced the Touch token to the UA string, which overlaps in >> intent with our Tablet token. >> >> Dao suggests it would be nice to get cross-browser consistency here. >> https://bugzilla.mozilla.org/show_bug.cgi?id=773355 >> >> This makes some sense to me. "Touch" is more the matter of interest than >> the form factor. If we do switch, we should do it before we ship native >> >> Fennec on tablets. >> >> Anyone want to argue for or against? >> >> Gerv > > I'm curious why there's a need here? In fact, I think I'd argue that form > factor was much more the driving interest behind the entire thing that > sparked including "Tablet" in the UA. > > Mobile wanted the word "Mobile" in the UA on small screen devices and not on > tablets in order to differentiate the two. Most sites are still sending > completely specialized content to small screen devices. Adapting an > estabilished site to a responsive design setup isn't going to be easy for > them (nor is it always possible), and they don't want to resort to slow stub > page tricks to find out form factor info. "Tablet" was added later when other > people became involved (and I argued against it at the time). > > Touch is a different ball though. Adapting for touch on the fly is > (arguably?) much MUCH easier than adapting your sites layout and design for > phone vs desktop/tablet. Things sites/we can do to make it better: I am not sure about this in the long run. It looks like sites are going towards being able to DOM-adapt to screens. And based in your point 3) It makes me think that sometimes UA detection servers as a temporary, handshake or special condition, for things that are not there yet in the DOM for all browsers so it feels "touch" tells more than screen at this point, IMHO. > > 1.) Sites can listen for touch events in addition to mouse ones. Its an > insignificant bit of extra code, and we should push for jQuery desktop and > other widget sets to start supporting touch as well. > > 2.) We should make sure touch-enabled media selectors are working so that > sites can optimize button sizes, layouts, etc. for touch screens if they > want. TBH, I haven't seen a strong need for this. Tablets for us are at least > 10in devices, and we lay them out at 980px wide by default. With those > settings, I've never had trouble with button or link sizes. > > 3.) We should also provide more reliable script hooks to detect if the device > supports touch? Right now I think sites just check for document.createTouch > which we turn off on desktop via a pref. > ___ > 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: HTTP-ON-EXAMINE-MERGED-RESPONSE
On 8/2/2012 3:19 PM, Jan Honza Odvarko wrote: According to the MDN here: https://developer.mozilla.org/en/Observer_Notifications#HTTP_requests HTTP-ON-EXAMINE-MERGED-RESPONSE is: called *instead* of http-on-examine-response when a response will be read partially from cache, and partially from the network (HTTP 206 or 304 response). Headers are available on the channel. --- But it looks like that HTTP-ON-EXAMINE-MERGED-RESPONSE can be sent *after* http-on-examine-response *and not instead* Could anybody confirm/verify? Thanks! Honza ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform What you say (that we call both) is definitely true when just simply looking into the code. It can be fixed, however in a bit dirty way. If you feel it should be fixed, please file a bug and CC me. -hb- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: "Touch" or "Tablet"?
On 8/2/12 8:59 AM, Mark Finkle wrote: 1. Let's not chase every browser's UA change. UAs _suck_ and I'd rather leave ours alone now that we fought through the debate. <3 UA changes just seem to be enormous time sinks relative to their value. I'd also prefer to see us changing it less, with the long-term goal of freezing / eliminating it (with some better-defined alternative, perhaps). Justin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
XULRunner builds on Mac and Windows are currently broken
Hi all, For the past couple of weeks these builds have been failing. Because they don't show up TBPL, there is little visibility into them, but these *are* shipping products and need to be fixed: Mac fails to successfully run configure: https://bugzilla.mozilla.org/show_bug.cgi?id=779907 Windows fails to compile: https://bugzilla.mozilla.org/show_bug.cgi?id=779910 Can someone please have a look at these? - Ben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Gecko 17 as the base for B2G v1
On 8/1/12 2:47 PM, Alex Keybl wrote: ... and on 11/19 work will move to the mozilla-esr17 branch. I don't really understand this, perhaps I am missing something? ESR and a v1.0 product seem inherently at odds. EG, I would assume that B2G will be making substantial and even high-risk changes right up to the day of release (and afterwards, should a 1.1 thing be needed). That's obviously different than ESR's primary goal, and even aurora/beta. I would have guessed B2G would want to create something like a "mozilla17-b2g" branch -- a stable (wrt non-B2G changes) Gecko 17 base, pulling in changes from aurora-17 / beta-17 as those trains run. But also allowing any changes B2G wants without worrying about impact to other products. Justin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Gecko 17 as the base for B2G v1
On 8/2/12 1:44 AM, Andreas Gal wrote: Reporting of the results and integration is very lacking, and until those pieces fall into place (e.g. try integration), the developer experience is going to suck a lot if we enforce the rule below (backout). That's the concern, yes. Basically, if we're going to have the rules proposed at the level of testing we have now then the path of least resistance for me is probably to land nothing else for the rest of the 17 cycle because it almost certainly save me a bunch of time to do things that way... If we get to a point where we have decent try test coverage, it's a different story. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Gecko 17 as the base for B2G v1
The ESR branch's purpose previously was to support enterprise deployments. Now that we are supporting both desktop deployments and B2G v1 on that branch, security/stability changes will not be the only fixes taken. There may be B2G-specific changes and minor cross-platform changes in support of B2G taken on that branch as well. -AlexMark Banner wrote:On 01/08/2012 22:47, Alex Keybl wrote: > On 10/7, we'll similarly move active B2G v1 platform development to > mozilla-beta, and on 11/19 work will move to the mozilla-esr17 branch. A > notice referencing this dev.platform post will be sent to the enterprise > list shortly for comment, as some of the ESR goals in [1] will need to > change slightly. Can you elaborate on the goal changes? The only thing I can see from your enterprise post is the addition of the support of B2G off the next ESR branch. If I'm understanding correctly then there is no intended affect on ESR itself? Thanks Mark. > [1] https://wiki.mozilla.org/Enterprise/Firefox/ExtendedSupport:Proposal ___ 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: Gecko 17 as the base for B2G v1
Your expectation that we'll still be taking major cross-platform changes to Gecko that late in the 17 cycle does not line up with the planning being done in the B2G dev team. If at any point it becomes clear that we need to pull B2G v1's Gecko off the trains for the sake of other products' qualIty, we'll create a separate branch entirely. We agreed that based upon current planning, it made more sense to be reactive than proactive here. -Alex Justin Dolske wrote:On 8/1/12 2:47 PM, Alex Keybl wrote: > ... and on 11/19 work will move to the mozilla-esr17 branch. I don't really understand this, perhaps I am missing something? ESR and a v1.0 product seem inherently at odds. EG, I would assume that B2G will be making substantial and even high-risk changes right up to the day of release (and afterwards, should a 1.1 thing be needed). That's obviously different than ESR's primary goal, and even aurora/beta. I would have guessed B2G would want to create something like a "mozilla17-b2g" branch -- a stable (wrt non-B2G changes) Gecko 17 base, pulling in changes from aurora-17 / beta-17 as those trains run. But also allowing any changes B2G wants without worrying about impact to other products. Justin ___ 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: "Touch" or "Tablet"?
On Thu, Aug 2, 2012 at 4:32 PM, Gervase Markham wrote: > http://blogs.msdn.com/b/ie/archive/2012/07/12/ie10-user-agent-string-update.aspx > > IE10 has introduced the Touch token to the UA string, which overlaps in > intent with our Tablet token. Opera and, IIRC, the RIM PlayBook browser say "Tablet". > Dao suggests it would be nice to get cross-browser consistency here. > https://bugzilla.mozilla.org/show_bug.cgi?id=773355 > > This makes some sense to me. "Touch" is more the matter of interest than > the form factor. If we do switch, we should do it before we ship native > Fennec on tablets. What if MS ships IE10 for phones with "Touch", too? Firefox's Mobile and Tablet tokens fit the taxonomy of Apple and Opera (though Apple spells theirs "iPad"). Microsoft's taxonomy is novel and it's unclear if it is the taxonomy that authors who UA sniff are interested in. > Anyone want to argue for or against? I want to argue against. -- 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
View port meta tag
Hi, all. I just tested view port meta tag on various devices and browsers. In chrome, opera and default browser for Android (4 at Galaxy Nexus) and on Blackberry 10 webkit all is good, when we pass in content attribute "width=device-width, initial-scale=1.0, user-scalable=no" both browsers scales page into screen and pass actual CSS/js width closer to 320 pixels. In same time gecko scale page to the view port closer to 320px, but does not changes innerWidth/document.body.offsetWidth to actual size of view port (~320 with scale factor ~2). Additionally, Nightly build for android have more strange behavior, it just scale page to view port, but do not perceives real device dpi or scale factor. So, in media queries Nightly always matches like a desktop with 96dpi. That do you think about this? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
MDN Kuma wiki launch Friday at 10 AM PDT
That's right! We're finally ready to throw the switch! Tomorrow (that is, Friday, August 3, 2012) we intend to switch from the current MindTouch-based wiki to our new Kuma platform for the Mozilla Developer Network wiki. The changeover should happen at about 10:00 AM Pacific Daylight Time. At that time, there should be, at most, a few moments of downtime, then the site should be running on the new system. A few things you might need to know: * There's lots more stuff we're planning to do to make Kuma even better than it already is. You may even notice some stuff that isn't done yet. However, weeks and weeks of testing have told us that it works very well, so we decided it was time to go ahead and launch. * We have updated documentation for using the wiki that you might like to look over, as well as an updated Editor guide. * Things are different! You will run into stuff that doesn't work the way you're used to. It should look pretty familiar, by and large, though, and most people won't notice the changes unless they look closely. * There's a big "Report a bug" button at the top-right corner of the window. Please use it! Any time you have a problem, concern, see something that looks wrong, or have an idea for a brilliant way to improve the system, click it and follow the handy wizard that will help you file your bug. We want the MDN wiki to rock, and you can help make it so. We will be sharing additional information about where we are and where things are going over the next week or two, and, of course, for the foreseeable future as we continue development. Indeed, the MDN development team is getting together for a week of meetings next week to rehash processes and sort out priorities for what to work on next. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Disabling tests
On Thu, 02 Aug 2012 10:22:43 -0500, Scott Johnson wrote: > Maybe we should take a different approach to the problem... > > Have an all-developer "fix orange tests" day where developers work ONLY > on fixing random oranges (maybe once you've successfully fixed 1 or 2 > random oranges, you can go back to your other work?) If it's random, how do you know if you've actually fixed it without having to waste your time watching the tree for a week? Phil -- Philip Chee , http://flashblock.mozdev.org/ http://xsidebar.mozdev.org Guard us from the she-wolf and the wolf, and guard us from the thief, oh Night, and so be good for us to pass. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Disabling tests
On Friday, 3 August 2012 02:30:03 UTC+1, Philip Chee wrote: > If it's random, how do you know if you've actually fixed it without > having to waste your time watching the tree for a week? http://brasstacks.mozilla.com/orangefactor/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MDN Kuma wiki launch Friday at 10 AM PDT
Hi, The #1 problem for many people with the current MDN wiki was that it didn't offer mediawiki-compatible markup editing. It would be great to be able to use right away one's familiarity with mediawiki markup (which is what most people know), and of course being able to copy and paste contents to/from mediawikis would be a huge benefit of that. Will the new wiki system offer that? Sorry, I hadn't heard of Kuma and a google search for Kuma Wiki didn't return useful results. Benoit 2012/8/2 Sheppy > That's right! We're finally ready to throw the switch! Tomorrow (that is, > Friday, August 3, 2012) we intend to switch from the current > MindTouch-based wiki to our new Kuma platform for the Mozilla Developer > Network wiki. The changeover should happen at about 10:00 AM Pacific > Daylight Time. > > At that time, there should be, at most, a few moments of downtime, then > the site should be running on the new system. > > A few things you might need to know: > > * There's lots more stuff we're planning to do to make Kuma even better > than it already is. You may even notice some stuff that isn't done yet. > However, weeks and weeks of testing have told us that it works very well, > so we decided it was time to go ahead and launch. > * We have updated documentation for using the wiki that you might like to > look over, as well as an updated Editor guide. > * Things are different! You will run into stuff that doesn't work the way > you're used to. It should look pretty familiar, by and large, though, and > most people won't notice the changes unless they look closely. > * There's a big "Report a bug" button at the top-right corner of the > window. Please use it! Any time you have a problem, concern, see something > that looks wrong, or have an idea for a brilliant way to improve the > system, click it and follow the handy wizard that will help you file your > bug. We want the MDN wiki to rock, and you can help make it so. > > We will be sharing additional information about where we are and where > things are going over the next week or two, and, of course, for the > foreseeable future as we continue development. Indeed, the MDN development > team is getting together for a week of meetings next week to rehash > processes and sort out priorities for what to work on next. > ___ > 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
