Re: [Advance warning] Session Restore is changing, will break add-ons
I talked to Gavin yesterday and we think the best approach would be to back out the Session Restore changes for now as they don't provide a real benefit other than code cleanup (and don't block any other work). The plan would then be to re-land them *with* a kill switch in the same cycle that brings Australis - so we would need to prepare and keep those patches ready. The reasoning is that we indeed will break different add-ons than Australis but at least there will only be one release with a couple of add-ons breaking instead of two in a row. For bug 838577 we will probably need to maintain a shadow tree as Johnathan mentioned. I would suggest we talk to Ehsan as he has experience in doing this successfully. - Tim On 05/22/2013 03:40 PM, David Rajchenbach-Teller wrote: > Opening Bug 874817 to add that kill switch. > > Just for clarification: we might kill add-ons that specifically look at > the contents of undocumented private data structures. The advance > warning is here because we know that some such add-ons exist. > > Given that all these refactorings take place on a single file, it might > make sense to just backout the changes if necessary. > > Cheers, > David > > On 5/22/13 3:35 PM, Johnathan Nightingale wrote: >> Policy[1] is that whenever something lands on central, it is the >> developer's responsibility to provide for the ability to turn it off. >> Usually that's just a kill switch in cases where it makes sense, or a >> backout where the patch is unlikely to accumulate much change on top of >> itself in a given release. >> >> In cases where neither of those works (Ehsan's private browsing changes, >> or dmandelin's landing of ionmonkey in FF18) engineers have had to work >> harder to maintain that ability, e.g. by maintaining a shadow tree that >> doesn't have their patches, but has all the other landings. That's what >> Ehsan's pointing to in his reply. >> >> I agree with Ehsan that, one way or another, we'll need to be able to >> disable these changes if they cause too much bustage (though I'm very >> happy to know that we're cleaning up that code in general). >> >> J >> >> >> [1] http://mozilla.github.io/process-releases/draft/development_overview/ >> Ancient, >> and shows it, but still relevant for this case. See "Moving work from >> one channel to another" >> >> --- >> Johnathan Nightingale >> VP Firefox Engineering >> @johnath >> > > -- Tim Taubert Firefox Engineer ttaub...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Extending the text-overflow/overflow property to support fading out
I'm pretty sure an unconditional mask with a linear gradient on the right-hand-end of the text could be achieved using 'mask-box-image' and slicing appropriately: http://www.w3.org/TR/css-masking/#the-mask-box-image. That's not currently implemented in Gecko, but it's worth implementing. A pure-CSS solution that makes the mask conditional on the text overflowing can't be implemented using any existing spec. I agree an extension to text-overflow would make the most sense. Rob -- q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q" ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: converting CPPSRCS to moz.build
On Wed 15 May 2013 12:23:41 AM EDT, Mike Shal wrote: On Mon 13 May 2013 04:17:39 PM EDT, Ryan VanderMeulen wrote: On 5/13/2013 4:08 PM, Ehsan Akhgari wrote: I don't see the downside of a very short tree closure. It is our common way of doing large scale stuff like this across the codebase. Agreed, no sense in tempting fate. Besides, 6am PT is a time where there's both good sheriff coverage and low activity. Seems like the right time to do it to me. Unfortunately this patch isn't ready yet. I'll have to postpone until another day :(. Hello again, Just a heads up, we're looking to get CPPSRCS into moz.build this coming Monday 5/27 starting at 11am Pacific. If this timeslot will cause any major conflicts please let me know. Thanks, -Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [RFC] Modules for workers
It should be possible to share some modules between Jetpack and Workers, for Jetpack modules that do not depend on DOM or XPCOM and Worker modules that do not depend on Worker-only code. This is not an immediate goal, but it is considered a-would-be-nice-to-have. Cheers, David On 5/20/13 8:53 PM, Dave Townsend wrote: > On the face of it it looks like it should be possible for Jetpack's > module loader to load these worker modules. Is that something that seems > desirable or are these modules not useful outside of workers? -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Geolocation and the Mac
On 5/22/13 9:49 AM, Doug Turner wrote: The Mac has a system where by location services for all apps are managed in a central place. We do not work in that system -- we do something different. This makes a user's view of how their location information is being share not complete. :( And we should change that. Agreed, I think better integration with OS-provided services is generally a swell thing. It just brings a bit of UX complexity in this case. Do the Core Location APIs provide a unique error code for when the user/OS has blocked permission? We know if the access to CoreLocations was denied. I am not sure if we can prompt the user again for permission if it was denied in the past. And if we could, I am not sure I would. What do you think dolske? We don't need to trigger the OS prompt again, just provide some info to the user to help them understand why Firefox's geolocation isn't working. The specific concern is that users won't understand that the one-time OS prompt can permanently block the browser's geolocation ability on all sites. The way Safari works is especially confusing -- the app will still prompt the user for permission on a site, but then the OS blocks the request. And so it seems like Safari is broken. (Of course if the user denies the browser's per-site prompt, this problem doesn't arise.) So, either (1) the browser's prompt should shown with some help for the "you told us 'yes' but told the os 'no' make up your mind" case, or (2) the browser's prompt should never be shown when the the OS won't let it work anyway. I don't think #2 is a good choice, because it feels more like a silent accidental failure mode than a solid indication of user intent. Justin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Hide Windows 7 and Windows XP jobs for Rev3 minis
Hi all, I would like to propose that we hide all Win7 and WinXP jobs running on rev3 minis since we have things running on the iX hardware. We would like to determine if we are ready to stop running jobs on the rev3 minis before stopping them. If you have no objections I will hide the builders by EOD. We can re-visit on Monday if we are ready to go ahead and stop running jobs on rev3 minis. There are some intermittent oranges that would be nice to deal with sooner than later (I have CCed the test owners were applicable): https://bugzilla.mozilla.org/show_bug.cgi?id=870453 https://bugzilla.mozilla.org/show_bug.cgi?id=874922 best regards, Armen PS = We will keep on running it for m-b, m-r, esr17 and b2g release branches. We will ride the trains. On 2013-05-17 1:07 PM, Armen Zambrano G. wrote: Hi all, As of today, we run in parallel Windows 7 and Windows XP on iX hardware as well as on minis. Current status: * Windows 7 on iX is running *visible* on FF23 based trees * Windows XP on iX is running *hidden* on m-i, try and cedar Sometime after Tuesday, I will: * Evaluate and propose a date for Win7 on iX to take over rev3 minis ** I have to fix a couple of issues * Make visible WinXP on iX (if it looks good) ** We will also enable it on all appropriate trees (if it looks good) We're also increasing the Windows ix pools (xp/w7/w8) a 30% (130 nodes each). If you find any blockers please add it to one of the bugs below. best regards, Armen https://tbpl.mozilla.org/?tree=Mozilla-Inbound&jobname=Windows%207 https://bugzilla.mozilla.org/show_bug.cgi?id=770578 https://tbpl.mozilla.org/?tree=Mozilla-Inbound&jobname=Windows%20XP https://bugzilla.mozilla.org/show_bug.cgi?id=770579 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Geolocation and the Mac
In Bug 874587, we are considering using Core Location as the default geolocation provider on the Mac. This would replace the use of the NetworkGeolocationProvider (that currently points to GLS). After code reviews, we plan to enable this on Nightly and see how it goes. On Android, we already due use the system location provider and not the NetworkGeolocationProvider... so this isn't something unexpected. The main difference is that you will get one prompt from the OS the first time you use geolocation from Firefox -- just like every other standard Mac application. Does anyone have any concern that is specific to change from the NetworkGeolocationProvider to a Mac platform specific one? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Extending the text-overflow/overflow property to support fading out
On 05/21/2013 05:31 PM, Jonathan Watt wrote: The design for the Australis theme refresh calls for tab text that needs to be truncated to be faded out instead of using an ellipsis. This fade should be a fixed width (say 2em) regardless of the width of the tab, and apparently needs to work over non-solid color backgrounds (so a right-aligned over the top with a fading out gradient won't work). Unfortunately we don't seem to have a good way to do that right now. Using an SVG mask containing a rect with a gradient fill you can kind of get close, but the width of the fade will vary with the width of the object to which the mask is being applied. (Extending SVG length attributes to support CSS calc() would help, but that's far from trivial.) One way to cater for this use case is perhaps to extend the 'text-overflow' property to take a value |fade | or |fade()| or something. Another more general solution might be to extend the 'overflow' property to take a value |fade-rect(, , , )| or something like that. Thoughts? First thought: I don't think this belongs on 'overflow'. That says how to handle overflow, not how to style the visible content. 'text-overflow: fade ' seems to make sense to me. But I can also see cases where you'd want to fade other kinds of overflow, too, though. I've also seen cases where you want to overlay a gray-transparent gradient, though, so it's not necessarily a fade that's wanted. Another consideration: do we want here a linear gradient or a Gaussian or some other curve? Also, this should probably go to www-style. ;) Wrt working around the SVG mask issues -- see the CSS Masking spec. It should handle what you want. The main issue is how to trigger it only when there's overflow. https://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html ~fantasai ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Geolocation and the Mac
Justin Dolske wrote: Yikes, this is crappy. The OS only asks once, and then your choice is (permanently?) stored in Preferences --> Security & Privacy --> Location Services. I had to google to find this, as Safari just silently passes on a failure to the site. I seriously wonder if we should have some UI (notification bar?) to note when Core Location fails (and send the user to a SUMO page explaining how to reenable it). We are doing exactly what Safari and other geolocation-enabled applications are doing. The Mac has a system where by location services for all apps are managed in a central place. We do not work in that system -- we do something different. This makes a user's view of how their location information is being share not complete. :( And we should change that. Do the Core Location APIs provide a unique error code for when the user/OS has blocked permission? We know if the access to CoreLocations was denied. I am not sure if we can prompt the user again for permission if it was denied in the past. And if we could, I am not sure I would. What do you think dolske? Doug ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [RFC] Modules for workers
On 5/18/2013 3:09 AM, David Rajchenbach-Teller wrote:
Hi everyone,
As part of the ongoing effort to make (Chrome) Workers useful for
platform refactorings, we have been working on a lightweight module
loader for workers (bug 872421). This loader implements a minimal
version of CommonJS modules, aka require.js.
Example:
// Setup the loader. We need this once per worker.
importScripts("resource://gre/modules/workers/loader.js");
// Import a few modules
let Logger = require("resource://gre/modules/workers/logger.js");
let Storage = require("resource://gre/modules/workers/storage.js");
// ...
// All values that are not exported are private to the module
// ...
exports.foo = function() { ... } // Export a value |foo|
exports.bar = 5; // Export a value |bar|
Once this loader lands, we will need some convention for where to place
modules for workers. Unfortunately, main thread modules (both .jsm and
Jetpack) can generally not be used by worker, due to different module
semantics, and more importantly due to the fact that most main thread
modules depend indirectly on XPCOM/XPConnect.
On the face of it it looks like it should be possible for Jetpack's
module loader to load these worker modules. Is that something that seems
desirable or are these modules not useful outside of workers?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Geolocation and the Mac
Asking the other way around, why are we doing this? Ad hoc it just looks like more code to maintain. We have been moving to system services where possible. We already did this on the Android. System service have a much better opportunity to already have location data allowing us to avoid a trip to GLS Also, is there documentation on how the mac does geo location? Yes. We also make statements about our requirements on 3rd party location services in https://www.mozilla.org/en-US/legal/privacy/firefox.html. Depending on how mac locates, those may or may not hold? This is not a 3rd party location service. This is part of the Core APIs of the operating system. The privacy policy may need to be modified before this change hits beta. I have already notified legal about the possiblity of this change. Doug ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Geolocation and the Mac
On 5/22/13 1:45 AM, Doug Turner wrote: In Bug 874587, we are considering using Core Location as the default geolocation provider on the Mac. This would replace the use of the NetworkGeolocationProvider (that currently points to GLS). After code reviews, we plan to enable this on Nightly and see how it goes. On Android, we already due use the system location provider and not the NetworkGeolocationProvider... so this isn't something unexpected. The main difference is that you will get one prompt from the OS the first time you use geolocation from Firefox -- just like every other standard Mac application. Does anyone have any concern that is specific to change from the NetworkGeolocationProvider to a Mac platform specific one? Asking the other way around, why are we doing this? Ad hoc it just looks like more code to maintain. Also, is there documentation on how the mac does geo location? We also make statements about our requirements on 3rd party location services in https://www.mozilla.org/en-US/legal/privacy/firefox.html. Depending on how mac locates, those may or may not hold? Axel ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Geolocation and the Mac
On 5/21/13 4:45 PM, Doug Turner wrote: The main difference is that you will get one prompt from the OS the first time you use geolocation from Firefox -- just like every other standard Mac application. Could be a little odd, but as long as it comes up after our own permission dialog it should be ok. I was curious if Safari was pre-cleared for this or not. Looks like it isn't -- I triggered geolocation from maps.google.com, then I got Safari's prompt for the page, and then an OS prompt regarding Safari was presented. Nice that they're playing by their own rules. :) But, hmm... Slightly worrysome -- I clicked "don't allow", and now I can't get Safari's geolocation to work. It's own dialog comes up, but I never get the OS prompt again (even after restarting the app). Yikes, this is crappy. The OS only asks once, and then your choice is (permanently?) stored in Preferences --> Security & Privacy --> Location Services. I had to google to find this, as Safari just silently passes on a failure to the site. I seriously wonder if we should have some UI (notification bar?) to note when Core Location fails (and send the user to a SUMO page explaining how to reenable it). Do the Core Location APIs provide a unique error code for when the user/OS has blocked permission? Justin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Modifying files in `testing/mozbase`
Recently we've started moving our in-tree harnesses (mochitest, reftest) to use a set of python libraries called "mozbase" (https://wiki.mozilla.org/Auto-tools/Projects/MozBase). I just wanted to bring up several things about this: 1. MozBase is developed on github (https://github.com/mozilla/mozbase), with the idea that having the code there helps make it more approachable for newcomers. The copy in mozilla-central is just a mirror. Our present policy is that changes should land in the github repository first, and only then be mirrored to mozilla-central. For more information on how this happens, see here: https://wiki.mozilla.org/Auto-tools/Projects/MozBase#Mirroring_to_Mozilla-Central 2. Any changes to the parts of mozbase which deal with Firefox must be backwards compatible with older versions. Mozbase is used by various regression-finding tools (e.g. mozregression) which can operate on a vast range of Firefox versions. For a real-world example, if you wanted to change the way the profile code (mozprofile) worked to support a new feature in Firefox, that would have to be done in a way such that the generated profile still worked with an older version. If that isn't possible by default, then the new behaviour must be made optional. If you have any questions, feel free to ask either me (wlach), Jeff Hammel (jhammel), Andrew Halberstadt (ahal) or Jonathan Griffin (jgriffin). We hang out on irc in #ateam. Will ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Running Windows 7 & XP jobs on ix hardware
On 2013-05-17 1:07 PM, Armen Zambrano G. wrote: * Windows XP on iX is running *hidden* on m-i, try and cedar I didn't see any perma-oranges so I made them visible. I will be adding the remaining branches tomorrow. cheers, Armen ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Extending the text-overflow/overflow property to support fading out
The design for the Australis theme refresh calls for tab text that needs to be truncated to be faded out instead of using an ellipsis. This fade should be a fixed width (say 2em) regardless of the width of the tab, and apparently needs to work over non-solid color backgrounds (so a right-aligned over the top with a fading out gradient won't work). Unfortunately we don't seem to have a good way to do that right now. Using an SVG mask containing a rect with a gradient fill you can kind of get close, but the width of the fade will vary with the width of the object to which the mask is being applied. (Extending SVG length attributes to support CSS calc() would help, but that's far from trivial.) One way to cater for this use case is perhaps to extend the 'text-overflow' property to take a value |fade | or |fade()| or something. Another more general solution might be to extend the 'overflow' property to take a value |fade-rect(, , , )| or something like that. Thoughts? http://dev.w3.org/csswg/css-ui/#text-overflow0 http://dev.w3.org/csswg/css-overflow/#overflow ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
new prefs for talos
Last week while investigating a crash on android which only happened in the
reftest and talos harness (not in the mochitest harness), we compared the
preferences. We found in mochitest we set a bunch of preferences to disable
background network access (intentionally designed to 404 for mochitest):
// Point the url-classifier to the local testing server for fast failures
user_pref("browser.safebrowsing.gethashURL",
"http://127.0.0.1:/safebrowsing-dummy/gethash";);
user_pref("browser.safebrowsing.keyURL",
"http://127.0.0.1:/safebrowsing-dummy/newkey";);
user_pref("browser.safebrowsing.updateURL",
"http://127.0.0.1:/safebrowsing-dummy/update";);
// Point update checks to the local testing server for fast failures
user_pref("extensions.update.url",
"http://127.0.0.1:/extensions-dummy/updateURL";);
user_pref("extensions.update.background.url",
"http://127.0.0.1:/extensions-dummy/updateBackgroundURL";);
user_pref("extensions.blocklist.url",
"http://127.0.0.1:/extensions-dummy/blocklistURL";);
user_pref("extensions.hotfix.url",
"http://127.0.0.1:/extensions-dummy/hotfixURL";);
// Turn off extension updates so they don't bother tests
user_pref("extensions.update.enabled", false);
// Make sure opening about:addons won't hit the network
user_pref("extensions.webservice.discoverURL",
"http://127.0.0.1:/extensions-dummy/discoveryURL";);
// Make sure AddonRepository won't hit the network
user_pref("extensions.getAddons.maxResults", 0);
user_pref("extensions.getAddons.get.url",
"http://127.0.0.1:/extensions-dummy/repositoryGetURL";);
user_pref("extensions.getAddons.getWithPerformance.url",
"http://127.0.0.1:/extensions-dummy/repositoryGetWithPerformanceURL";);
user_pref("extensions.getAddons.search.browseURL",
"http://127.0.0.1:/extensions-dummy/repositoryBrowseURL";);
user_pref("extensions.getAddons.search.url",
"http://127.0.0.1:/extensions-dummy/repositorySearchURL";);
// Make sure that opening the plugins check page won't hit the network
user_pref("plugins.update.url",
"http://127.0.0.1:/plugins-dummy/updateCheckURL";);
We landed these prefs for android based reftests and the crash has gone away,
we will be doing the same for talos. In thinking about it more, it makes sense
to add these to desktop Talos as well.
Is there any reason why we shouldn't be setting these preferences for desktop
Talos?
Should any of those be adjusted?
Thanks!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Extending the text-overflow/overflow property to support fading out
On 21/05/2013 11:04, fantasai wrote:
First thought: I don't think this belongs on 'overflow'. That
says how to handle overflow, not how to style the visible content.
In the case of extending 'overflow', I'd imagine the fade would go on the
outside of the clip rect rather than on the inside. I.e.:
|<--- border-box width --->|
|<--- width of the content that's inside the element --->|
fade area --->| |<---
rather than:
|<--- border-box width --->|
|<--- width of the content that's inside the element --->|
fade area --->| |<---
Combined with a matching length for 'margin-right' that would seem to work, but
very possibly it's not what you'd want in general.
'text-overflow: fade ' seems to make sense to me. But
I can also see cases where you'd want to fade other kinds of
overflow, too, though.
Are you thinking specifically of the overflow controlled by the 'overflow'
property, or something else?
I've also seen cases where you want to
overlay a gray-transparent gradient, though, so it's not
necessarily a fade that's wanted.
When would you want that rather than a gradient mask?
Another consideration: do we want here a linear gradient or a
Gaussian or some other curve?
I was thinking linear would be most widely useful and keep things simple, but
maybe it's just wishful thinking.
Also, this should probably go to www-style. ;)
Indeed. I was just looking for some moz community thoughts and sanity checking
before we take anything to www-style.
Wrt working around the SVG mask issues -- see the CSS Masking
spec. It should handle what you want. The main issue is how
to trigger it only when there's overflow.
Interesting. But without some sort of calc() support in linear-gradient(), I
don't think that linear-gradient() would solve the Australis theme use case. We
basically want to mask with a mask containing a gradient producing "maximum
luminosity from the start of the element to calc(width-2em), then fades to zero
from calc(width-2em) to width".
Allowing SVG gradients to be referenced from linear-gradient() doesn't seem to
provide the flexibility we need, since the way that objectBoundingBox is defined
prevents s with units from being usable inside such a mask. That's
because objectBoundingBox is defined in terms of a transform that maps 1px to be
the width/height of the element's bbox. The only realistic way to allow the
content of a mask to have percentage lengths that are resolved against the size
of the element _and_ s with units is to add a third value for
maskContentUnits, I think. ("objectBoundingBox2"?)
BTW, for the Australis theme, it may be acceptable to just have the right hand
side of the text fade regardless of whether it actually overflows or not.
Thanks,
Jonathan
https://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html
~fantasai
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Visual C++ PGO linker memory usage
Woohoo! Great. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [Advance warning] Session Restore is changing, will break add-ons
Opening Bug 874817 to add that kill switch. Just for clarification: we might kill add-ons that specifically look at the contents of undocumented private data structures. The advance warning is here because we know that some such add-ons exist. Given that all these refactorings take place on a single file, it might make sense to just backout the changes if necessary. Cheers, David On 5/22/13 3:35 PM, Johnathan Nightingale wrote: > Policy[1] is that whenever something lands on central, it is the > developer's responsibility to provide for the ability to turn it off. > Usually that's just a kill switch in cases where it makes sense, or a > backout where the patch is unlikely to accumulate much change on top of > itself in a given release. > > In cases where neither of those works (Ehsan's private browsing changes, > or dmandelin's landing of ionmonkey in FF18) engineers have had to work > harder to maintain that ability, e.g. by maintaining a shadow tree that > doesn't have their patches, but has all the other landings. That's what > Ehsan's pointing to in his reply. > > I agree with Ehsan that, one way or another, we'll need to be able to > disable these changes if they cause too much bustage (though I'm very > happy to know that we're cleaning up that code in general). > > J > > > [1] http://mozilla.github.io/process-releases/draft/development_overview/ > Ancient, > and shows it, but still relevant for this case. See "Moving work from > one channel to another" > > --- > Johnathan Nightingale > VP Firefox Engineering > @johnath > -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [Advance warning] Session Restore is changing, will break add-ons
On May 22, 2013, at 5:33 AM, David Rajchenbach-Teller wrote: > Unfortunately, we do not. > > For the current batch of clean-up changes, it is certainly possible to > add a kill switch. Time-consuming, certainly not nice (the kill switch > will creep in in dozens of places in the code, if not hundreds), but > possible. > > For the upcoming set of rewrite-half-of-the-code changes, though, having > a kill switch pretty much means forking the code of Session Restore into > an "old" session restore and a new one. > > Do we have a policy on these things? Policy[1] is that whenever something lands on central, it is the developer's responsibility to provide for the ability to turn it off. Usually that's just a kill switch in cases where it makes sense, or a backout where the patch is unlikely to accumulate much change on top of itself in a given release. In cases where neither of those works (Ehsan's private browsing changes, or dmandelin's landing of ionmonkey in FF18) engineers have had to work harder to maintain that ability, e.g. by maintaining a shadow tree that doesn't have their patches, but has all the other landings. That's what Ehsan's pointing to in his reply. I agree with Ehsan that, one way or another, we'll need to be able to disable these changes if they cause too much bustage (though I'm very happy to know that we're cleaning up that code in general). J [1] http://mozilla.github.io/process-releases/draft/development_overview/ Ancient, and shows it, but still relevant for this case. See "Moving work from one channel to another" --- Johnathan Nightingale VP Firefox Engineering @johnath ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: HTML Working Group
On 22/05/13 03:09, L. David Baron wrote: > On Friday 2013-02-08 14:37 -0800, L. David Baron wrote: >> W3C is proposing a revised charter for the HTML Working Group. >> For more details, see: >> http://lists.w3.org/Archives/Public/public-new-work/2013Feb/0009.html >> http://www.w3.org/html/wg/charter/2012/ >> >> Mozilla has the opportunity to send comments or objections through >> Tuesday, March 12. Please reply to this thread if you think there's >> something we should say. > > A bit of followup here. One of the pieces of feedback I got as part > of the previous round of review was that we should push for at least > allowing *experimentation* with more open document licenses than the > W3C currently allows. As a result, the W3C has proposed a revised > charter with this modification and a few other small modifications > resulting from the review. I've described the rationale for this > and the sequence of events in a bit more detail here: > http://dbaron.org/log/20130522-w3c-licensing > > This means there's currently another charter review period going on, > to review this new charter: > http://lists.w3.org/Archives/Public/public-new-work/2013May/.html > http://www.w3.org/html/wg/charter/2013/ Thank you for doing that David, this is a great step forward :) -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [Advance warning] Session Restore is changing, will break add-ons
Unfortunately, we do not. For the current batch of clean-up changes, it is certainly possible to add a kill switch. Time-consuming, certainly not nice (the kill switch will creep in in dozens of places in the code, if not hundreds), but possible. For the upcoming set of rewrite-half-of-the-code changes, though, having a kill switch pretty much means forking the code of Session Restore into an "old" session restore and a new one. Do we have a policy on these things? Cheers, David On 5/22/13 5:16 AM, Ehsan Akhgari wrote: > Do we have a kill switch for the new stuff (a build-time flag or a > runtime pref) which we can use to turn this off on Beta if the add-on > compatibility problem proves to be bad enough that we would need to wait > for a while before we can ship this? I have experience maintaining a > branch to build and test Firefox with per-window private browsing turned > off at build-time which I used when Firefox 20 migrated through our > release channel and finally shipped. I would be happy to help you on > doing the same thing if needed. > > Cheers, > Ehsan > -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
