Re: Editor / IDE integration docs
So, Ting-Yu pointed me to [1], which I didn't find because I had the great idea of searching from within MDN, and those pages apparently don't show up in results at all[2] :/. That also has a bunch of extra resources linked in like [3] and [4]. So I'll try to see what's relevant and what's not, and move most of that to the in-tree docs, assuming that there are no objections :) -- Emilio [1]: https://developer.mozilla.org/en-US/docs/Developer_Guide/Editor_Configuration [2]: https://developer.mozilla.org/en-US/search?q=editor+configuration [3]: https://wiki.mozilla.org/DevTools/CodingStandards [4]: https://wiki.mozilla.org/WebExtensions/Hacking#Vim On 4/13/20 11:52 PM, Emilio Cobos Álvarez wrote: Hey, A semi-frequent question in #developers or #introduction is to ask about which IDE or editor people use, or how to get X working on Y editor, etc. I've sent a patch to document what I know to: https://bugzilla.mozilla.org/show_bug.cgi?id=1629445 Which is already on autoland. But I arguably don't know all that much, as my setup is fairly simple, just vim and ycm :) If your favorite editor tweaks and such aren't listed there and you have some time to document them to help newcomers and lazy oldcomers[1] alike, please take a moment to document them in that page! Thank you! -- Emilio [1]: for example, I'd be curious to know if there's an easy way to show the clang-tidy / eslint diagnostics that Phabricator always shouts about inline in my editor :) ___ 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
Editor / IDE integration docs
Hey, A semi-frequent question in #developers or #introduction is to ask about which IDE or editor people use, or how to get X working on Y editor, etc. I've sent a patch to document what I know to: https://bugzilla.mozilla.org/show_bug.cgi?id=1629445 Which is already on autoland. But I arguably don't know all that much, as my setup is fairly simple, just vim and ycm :) If your favorite editor tweaks and such aren't listed there and you have some time to document them to help newcomers and lazy oldcomers[1] alike, please take a moment to document them in that page! Thank you! -- Emilio [1]: for example, I'd be curious to know if there's an easy way to show the clang-tidy / eslint diagnostics that Phabricator always shouts about inline in my editor :) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to unship AppCache
Hi everyone, Jonathan is unfortunately not with the company anymore so I wanted to follow-up and clarify our current timeline for disabling appcache. It is my intention to land bug 1619673 [1] in Firefox 77 and let it ride the trains. We would keep the pref off in 78 because that's an ESR release, in case there's a critical use case for it (we could add an enterprise policy for it, or re-enable it if needed) but that's unlikely to happen. Starting with 79 we can start removing the code that backs appcache, such as the old and slow . The intention for now is to leave the dom property window.applicationCache and the “OfflineResourceList” interface in place for the foreseeable future in order to avoid websites breaking. Note that appcache use is still very low [2]. Assuming Chrome keeps to their plan [3][4] they should also be disabling this around the end of June. As stated in the previous email, appcache is a progressive enhancement, so removing it doesn't break the web. Thanks! [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1619673 [2] https://georgf.github.io/usecounters/index.html#kind=page=OFFLINERESOURCELIST=beta=75 [3] https://www.chromestatus.com/features/6192449487634432 [4] https://bugs.chromium.org/p/chromium/issues/detail?id=582750#c47 On Fri, 30 Aug 2019 at 00:30, Jonathan Kingston wrote: > I spoke to some folks who work on Chrome and they suggested because of > their larger usage numbers there wasn't a concrete timeline that they were > working towards, however they think there is an active plan to exchange > appcache for service worker on some Google products they have which will > aid in it's removal in the browser. > > Due to the code freeze we should increase all those version numbers by one > in my original email, however I believe we should continue with this plan: > - As our usage numbers are much lower. > - Appcache is unique feature in that it's largely a progressive > enhancement, so removing it doesn't break the web as a whole. > - Removing this code is a bigger benefit to Firefox users from a > performance and security standpoint. > > Thanks > > On Thu, Aug 22, 2019 at 2:45 PM Andrew Overholt > wrote: > > > It's been a long time coming :) Do you know if Chrome plans to drop > > support, too? > > > > On Wed, Aug 21, 2019 at 5:01 PM Jonathan Kingston > wrote: > > > >> The design of AppCache brings many problems to the web platform from a > >> performance and security perspective. Service workers have long solved > the > >> same use cases as AppCache. > >> > >> Removal of this code would bring a large reduction of code and > complexity > >> that is largely unmaintained. > >> > >> History > >> > >> Four years ago, in Firefox 44, we marked the API as deprecated[1]. > >> > >> Back last year in Firefox 62, we disabled insecure AppCache and Chrome > >> followed suit[2]. > >> > >> Safari 11.1 added support for Service Workers, which are a replacement > >> technology [3]. > >> > >> Metrics > >> > >> Chrome measures a few different metrics here which suggest 2.3%[4] of > >> secure page loads attempt to use the document visible API whilst only > >> 0.27%[5] actually use the offline cache. > >> > >> Firefox metrics suggest around 0.01% of pages are using an AppCache[6] > >> however we don’t have a distinct metric for the API usage. > >> > >> The last blocker for a removal was usage of AppCache by some Microsoft > >> online products. I’m enquiring into if this is still applicable and > also > >> want to ensure with this rollout plan that we don’t break these when the > >> user has an online connection. > >> > >> Implementation > >> > >> Bug where the code will be implemented[7]. > >> > >> Plan > >> > >>- > >> > >>In Firefox 70, Remove the previous preference > >>“browser.cache.offline.insecure.enable” and related code, forcing all > >> of > >>the APIs to only ever be available over Secure Contexts despite user > >>choice. Due to the insecure nature of insecure context AppCache it > is a > >>good time now to remove this fully. > >> > >> > >>- > >> > >>Create a new preference that disables only the storage and use of > >>AppCache data whilst permitting access to the dom property > >>window.applicationCache and the “OfflineResourceList” interface. > >>- > >> > >> Disable access in Nighty and beta for 70 for two releases before > >> disabling for all other releases in 72. > >> - > >> > >> Once storage is disabled in all releases: > >> - > >> > >> Disable the API access in Nightly and beta via the existing > >> preference (browser.cache.offline.enable) in version 72. > >> - > >> > >> Wait two releases and then disable in all releases in Firefox > 74. > >> > >> > >> This staged removal of AppCache is to reduce the risk of web > compatibility > >> issues of the API being accessible to page scripts. Despite the API > >> presence it won’t have any ability to use the cache. We may
Re: Deprecation notice - change to Treeherder's jobdetail API
The reason my answer has been overly broad is because the type of data that is being parsed by TinderboxPrint lines is inconsistent. Some of its CPU/resource stats that should be reported to Perfherder, some of it is urls embedded in html, and some is other bits of data (for example): ``` "title": "(unnecessary roots)", "value": "1001", "url": null ``` So the answer to "what do we do instead' is "it depends" but we'll help people figure it out on a case-by-case basis. Sarah On Mon, Apr 13, 2020 at 10:38 AM Nicholas Alexander wrote: > Hi all, > > On Mon, Apr 13, 2020 at 10:29 AM Sarah Clements > wrote: > >> Nick, >> >> I want to clarify something I said in my previous email that might be >> confusing: >> > We currently process data from the jobInfo and extra.artifacts >> properties of jobs we ingest (this goes into the JobDetails table). >> >> Disregard this, it's mostly specific to Treeherder (I think we're >> primarily using extra.artifacts for Perfherder and I am cautious about >> using it as a catch-all for random bits of information). An alternative for >> surfacing whatever information is currently being parsed by TinderboxPrint >> lines is to create a structured artifact (if, as I mentioned previously, >> it's not stats that should be reported to Perfherder). If this doesn't work >> for your scenario, we can pull in people more familiar with >> tests/harnesses/etc to help figure out what you need and how to surface it >> (:jmaher might be a good person to ask). >> >> When you get an idea of what you need to do, let me know an estimation of >> your timeline. I can extend the deadline by another month or two (*just >> for TinderboxPrint deprecation*) so everyone who needs to can get >> alternatives implemented can. >> > > To be clear: I don't need or expect an extension of this deadline. I'm > not thrilled that we don't have a crisp answer to "what do I do instead", > but I trust that the people closest to this problem -- namely, you -- are > balancing things reasonably and I fully support the decision you are > presenting. > > Best, > Nick > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Deprecation notice - change to Treeherder's jobdetail API
Hi all, On Mon, Apr 13, 2020 at 10:29 AM Sarah Clements wrote: > Nick, > > I want to clarify something I said in my previous email that might be > confusing: > > We currently process data from the jobInfo and extra.artifacts > properties of jobs we ingest (this goes into the JobDetails table). > > Disregard this, it's mostly specific to Treeherder (I think we're > primarily using extra.artifacts for Perfherder and I am cautious about > using it as a catch-all for random bits of information). An alternative for > surfacing whatever information is currently being parsed by TinderboxPrint > lines is to create a structured artifact (if, as I mentioned previously, > it's not stats that should be reported to Perfherder). If this doesn't work > for your scenario, we can pull in people more familiar with > tests/harnesses/etc to help figure out what you need and how to surface it > (:jmaher might be a good person to ask). > > When you get an idea of what you need to do, let me know an estimation of > your timeline. I can extend the deadline by another month or two (*just > for TinderboxPrint deprecation*) so everyone who needs to can get > alternatives implemented can. > To be clear: I don't need or expect an extension of this deadline. I'm not thrilled that we don't have a crisp answer to "what do I do instead", but I trust that the people closest to this problem -- namely, you -- are balancing things reasonably and I fully support the decision you are presenting. Best, Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Deprecation notice - change to Treeherder's jobdetail API
Nick, I want to clarify something I said in my previous email that might be confusing: > We currently process data from the jobInfo and extra.artifacts properties of jobs we ingest (this goes into the JobDetails table). Disregard this, it's mostly specific to Treeherder (I think we're primarily using extra.artifacts for Perfherder and I am cautious about using it as a catch-all for random bits of information). An alternative for surfacing whatever information is currently being parsed by TinderboxPrint lines is to create a structured artifact (if, as I mentioned previously, it's not stats that should be reported to Perfherder). If this doesn't work for your scenario, we can pull in people more familiar with tests/harnesses/etc to help figure out what you need and how to surface it (:jmaher might be a good person to ask). When you get an idea of what you need to do, let me know an estimation of your timeline. I can extend the deadline by another month or two (*just for TinderboxPrint deprecation*) so everyone who needs to can get alternatives implemented can. Sarah ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Deprecation notice - change to Treeherder's jobdetail API
Hi Steve,
You will still be able to see all uploaded artifacts in the Treeherder job
detail panel. The difference is that we will be retrieving them from
taskcluster directly rather than storing them in our database and
retrieving them that way.
Regarding your use of log lines, if you can create a structured artifact
(JSON, as you mentioned) that would probably be the way to go. If it's
stats, that should be reported to Perfherder. If that doesn't work for your
particular scenario, then we can loop in other people (maybe :jmaher) who
have more knowledge of tests/harnesses/etc to figure out how to surface the
info you need. In general, we don't really have an intended replacement per
say for TinderboxPrint. It's more a matter of figuring out who is using it,
whether we already have that data stored elsewhere in Treeherder and if
not, how we can surface it using existing avenues.
Let me know if you need a longer timeline for implementing this. I can
extend the deadline by another month or two (*just for TinderboxPrint
deprecation*) so everyone who needs to can get alternatives implemented can.
Sarah
On Fri, Apr 10, 2020 at 11:03 AM Steve Fink wrote:
> On 4/10/20 10:06 AM, Andrew McCreight wrote:
> > On Thu, Apr 9, 2020 at 6:51 PM Sarah Clements
> wrote:
> >
> >> Hello,
> >>
> >> As part of maintenance work and performance improvements to Treeherder,
> >> we're making changes to some of the data that's stored in our database.
> On *April
> >> 30th*, we will no longer be retrieving uploaded artifacts for jobs and
> >> storing them in the JobDetail table.
> >>
> >> Uploaded artifacts can be retrieved via a taskcluster API, with the
> >> appropriate rootUrl, taskId and runId. TaskId and runId (synonymous with
> >> retryId in Treeherder) can be surfaced from any of our /jobs/ API's. See
> >> this
> >> <
> https://github.com/mnoorenberghe/mozscreenshots/issues/43#issue-592994567>
> >> for implementation details.
> >>
> > As somebody who has dumped files to MOZ_UPLOAD_DIR and used the job
> detail
> > tab to download those files (just this week, in fact!), but has only a
> > vague idea of what the "taskcluster API" even is, let alone a "rootURL"
> or
> > the rest of it, is there any introductory documentation about how I might
> > retrieve files written to MOZ_UPLOAD_DIR? Am I going to have to write
> some
> > kind of Python script to retrieve my files in the future? That GitHub
> issue
> > seems to require a lot of background information that I do not have.
>
> I'm in a similar boat. I very frequently set additional options on my
> try pushes in order to generate nondefault files in MOZ_UPLOAD_DIR. It
> is unclear to me from this description whether I will still be able to
> see those files in the treeherder UI after this change.
>
> >
> >> We're also planning to deprecate the parsing and storage of
> TinderboxPrint
> >> log lines in the JobDetail table. They'll no longer be shown in
> >> Treeherder's job detail panel but you can still read them in the raw
> logs
> >> via the log-viewer.
> >>
> >> If you have any questions or concerns (or need a longer timeline to make
> >> changes that rely on this data), don't hesitate to reach out.
>
> Similarly, I also regularly depend on being able to emit log lines from
> my jobs that will be easily visible in treeherder (*without* reading the
> entire raw log), both for my own use and others'. Is there a replacement
> for this functionality? I am not at all sad to see the specific
> implementation go ("TinderboxPrint" plus an opaque set of rules for what
> can go after it), and would be happy to convert my jobs over to a
> different system. If that involves something like writing out structured
> json to a separate file, that's still fine with me. (I'm only speaking
> for myself; some people may depend on being able to simply drop in
> `fprintf(stderr, "TinderboxPrint: ...")` into their code and have it
> show up.)
>
> Needing to load the raw log files isn't great because (1) it takes a
> noticeable amount of time for large files (I'm sure this is much worse
> for some locations), and (2) when you're doing things like this, you may
> very well need to be loading several of them.
>
> If there *is* an intended replacement, I could suggest other things that
> I'd find useful (or would like to preserve with the current setup). For
> example, I have a job that checks for multiple types of errors, and
> wants to output a link to documentation specific to the class of error
> that was detected. Not critical functionality, but it definitely makes
> for a better workflow. I am currently using TinderboxPrint for this, in
> a way that once worked but has now regressed. Example: see the
> 'documentation' link in Job Details at
>
> https://treeherder.mozilla.org/#/jobs?repo=try=sfink%40mozilla.com=39a2e0ffb371099b5ffd42cb7932367a183d6128=295880330
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
Re: Intent to implement: Cookie SameSite=lax by default and SameSite=none only if secure
четверг, 23 мая 2019 г., 11:34:14 UTC+3 пользователь Andrea Marchesini написал: > Link to the proposal: > https://tools.ietf.org/html/draft-west-cookie-incrementalism-00 > > Summary: > "1. Treat the lack of an explicit "SameSite" attribute as >"SameSite=Lax". That is, the "Set-Cookie" value "key=value" will >produce a cookie equivalent to "key=value; SameSite=Lax". >Cookies that require cross-site delivery can explicitly opt-into >such behavior by asserting "SameSite=None" when creating a >cookie. >2. Require the "Secure" attribute to be set for any cookie which >asserts "SameSite=None" (similar conceptually to the behavior for >the "__Secure-" prefix). That is, the "Set-Cookie" value >"key=value; SameSite=None; Secure" will be accepted, while >"key=value; SameSite=None" will be rejected." > > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1551798 > > Platform coverage: all > > Estimated or target release: 69 - behind pref > > Preferences behind which this will be implemented: > - network.cookie.sameSite.laxByDefault > - network.cookie.sameSite.noneRequiresSecure (this requires the previous > one to be set to true) > > Is this feature enabled by default in sandboxed iframes? yes. > > Do other browser engines implement this? > - Chrome is implementing/experimenting this feature: > https://blog.chromium.org/2019/05/improving-privacy-and-security-on-web.html > - Safari: no signal yet. > > web-platform-tests: There is a pull-request > https://github.com/web-platform-tests/wpt/pull/16957 > Implementing this feature, I added a mochitest to inspect cookies via > CookieManager. > > Is this feature restricted to secure contexts? no ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
