>
> How we populate the new profile we create for Nightly and Beta channels is
> an open question. We could simply clone the existing Release profile or use
> Firefox Refresh to copy across the basic data. In either case we can notify
> the user to let them know what has happened.
>
Use some cauti
What happens when users do that? Because they do.
A variety of kinda-horrible things will happen.
The two copied profiles will compete for the Sync client record. That means
sent tabs will appear on one or the other, the Tabs from Other Devices list
will flip-flop between each of the two device
I should add that there are ways to detect and work around these situations, of
varying levels of difficulty and specificity*; if there's sufficient motivation
I can flesh out a bug.
* E.g., using server timestamps to detect whether another client is racing with
us, and deciding that a profile
Welcome to the fourth Browser Architecture Newsletter!
A lot of the issues that the Browser Architecture team are digging into are
larger than our team. Our goal is to discuss and review entire product
level architecture issues and build consensus around solutions. We’re
interested in engaging wit
>
> Are there alternative ways we could achieve the same without the (or with
> low) complexity/overhead?
>
If I'm understanding correctly what you're trying to do, the typical
suggestion here is to not use global singletons. That way you don't need to
dig into the guts of a globally visible objec
>
> We have quite a bit of ongoing activity linked from
> https://bugzilla.mozilla.org/show_bug.cgi?id=1147820 focused on APIs
> exposed to web content (HTTP cache, cookies, localStorage, Indexed DB,
> service worker registrations, etc.) and the associated UI exposed to
> users. There should maybe
>
> From your addressing, I assume most of the communication from/to this
> group should happen on either firefox-dev or dev-platform?
>
Re direction and strategy, the goal here is *not* to silo important
technical decisions; it's to make sure that a set of people have explicit
responsibility for
>
> Both of these behaviours are incompatible with reviewer-initiated landing.
>
I've fallen on both sides of this particular fence; sometimes I want to
fire-and-forget a patch, and sometimes I still want to digest further after
getting review (or I know a piece of work is incomplete and further p
>
> Starting in the second quarter of this year, if you’ve taken on a
> component, I’m expecting you or your team to look at the bugs which landed
> in the component on a more frequent basis than a weekly triage.
>
In my experience, component watching adequately serves this purpose, and
component
Here's my very lightweight counter-proposal:
Once or twice a week, automatically mail out two lists (in one email) to
the set of people Emma collected. The first are is UNCONFIRMED bugs. The
second is NEW bugs, not filed by one of the reviewers or bug admins of that
component, that haven't been to
On Friday, March 21, 2014 12:16:28 AM UTC-7, Gregory Szorc wrote:
> What other solutions besides concatenating files and lazy loading are there?
> Neither sound particularly appealing to me. I'd really like to be able to
> "pin" specific JSMs to shared compartments. Kind of a hybrid between CPG
11 matches
Mail list logo
