Re: removing blank lines at beginnings and ends of JS blocks

[Myk Melez]

Myk Melez wrote on 2019-01-28 09:46:
This week I plan to remove blank lines at the beginnings and ends of 
JS blocks and update the global eslint configuration file to prohibit 
them by landing the patch in bug 1518283 
<https://bugzilla.mozilla.org/show_bug.cgi?id=1518283>.
Update: I landed this on Wednesday, and it stuck 
<https://hg.mozilla.org/mozilla-central/rev/73a91e84dbec>.


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

removing blank lines at beginnings and ends of JS blocks

[Myk Melez]

Developers,

This week I plan to remove blank lines at the beginnings and ends of JS 
blocks and update the global eslint configuration file to prohibit them 
by landing the patch in bug 1518283 
.


Note that I'm not removing all blank lines, only those at the beginnings 
and ends of blocks, which eslint calls padded-blocks 
.


Most JS blocks in the tree are already unpadded, and we already prohibit 
padded blocks in a number of subdirectories 
.


Prohibiting them tree-wide is consistent with Mark Banner's plan for 
eslint rule harmonization 
.


The patch may conflict with other patches-in-progress, given my 
experience maintaining a branch with the changes over the last few 
weeks. However, the conflict resolution is straightforward, since the 
only change being made is the removal of entirely blank lines. And 
annotation (blame) views of the codebase are unaffected, since removed 
lines don't show up there.


Let me know if you have any questions or concerns.

Cheers,
-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Workflow Apropos!

[Myk Melez]

James Graham wrote on 2018-11-28 13:20:

On 28/11/2018 20:15, Mark Côté wrote:
My team has pretty much nothing to do with the gecko GitHub clone; we 
need to keep our focus on the "standard" workflow.


Sure, the problem is that it's an attractive nuisance for new 
contributors who find it and go "It's a GitHub repo! I know this" 
without realising it's largely unsupported.
I've updated the description of the repo to emphasize that it's 
unsupported and direct readers to its website for further details.


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: mozilla-inbound backout policy subject to change (become similar to autoland)

[Myk Melez]

Sebastian Hengst wrote on 2018-08-09 08:51:
Tier 2 jobs are going to be re-evaluated if that tier is still 
suitable or if it's something which should not be broken because we 
rely on it (e.g. QuantumRender, Btup is also heading for this).
Good to know, thanks, Sebastian. Is there a way to track that 
re-evaluation, perhaps a bug or a thread in another forum? (It's ok if 
not, as long as there's a way to find out the result, such as a post to 
this thread once a decision has been made.)


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: mozilla-inbound backout policy subject to change (become similar to autoland)

[Myk Melez]

Boris Zbarsky wrote on 2018-06-26 21:53:

On 6/27/18 12:50 AM, Mike Hommey wrote:

Perma bustage of tier-2 jobs usually do.


Of a bunch of them, or of just one tier-2 job (but permanent bustage 
across all pushes)?


My understanding was that tier-2 meant it can be broken for a bit 
without backout happening.  If that's not the case, how does it differ 
from tier-1?

Boris, did you ever get an answer to this question?

It remains relevant, as I just had a change [1] backed out immediately 
for busting Btup, which is currently categorized as tier-2.


Sheriffing/Job Visibility Policy [2] describes tier-2 as:
Jobs are shown by default on Treeherder, but are not sheriff-managed. 
Results will be shown on Treeherder "for information only". New test 
failures/bustage will not result in a backout, but a tracking bug will 
be filed when observed.
It seems like this document is either out-of-date, and the tier-2 policy 
has changed, or Btup is miscategorized.


-myk

[1] 
https://phabricator.services.mozilla.com/rMOZILLACENTRAL08fa47a24e89697e4e43177860b55cc28298bbff
[2] 
https://wiki.mozilla.org/Sheriffing/Job_Visibility_Policy#Overview_of_the_Job_Visibility_Tiers


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: C++ standards proposal for a embedding library

[Myk Melez]

Botond Ballo wrote on 2018-07-18 09:45:

As we have some experience in the embedding space here at Mozilla, I
was wondering if anyone had feedback on this embedding library
proposal. This is an early-stage proposal, so high-level feedback on
the design and overall approach is likely to be welcome.
I'm afraid that I agree with the consensus in this thread: specifying a 
web_view class isn't a useful activity for the C++ standards committee 
to undertake.


The proposal notes that C++ specifies "no useful facilities" for 
creating graphical interfaces, so "users either need to make use of 
system-specific APIs, third-party libraries, or move to a different 
programming language."


However, it doesn't explain why "system-specific APIs" and "third-party 
libraries" are considered insufficient or harmful. As others have 
pointed out, for languages with first-class modules and package 
ecosystems, third-party libraries are a feature of a language, not a 
bug. And "system-specific APIs" have their own advantages (along with 
downsides).


The proposal also notes, "To be useful, we’ll need to require support 
for a large number external standards (i.e., [X]HTML, CSS, SVG, 
ECMAScript, and possibly others). Our three-year release cycle is likely 
sufficient to maintain a proper list of such standards, but it’s still a 
large list, and to be clear, the transitive closure of this list is huge."


At the very least, this statement is worthy of more careful 
consideration, given the ongoing rapid change in the web platform 
surface area (not to mention implementation strategies that affect 
embedding APIs, such as the move to multiple content processes).


And it notes, "Surveying the current implementations has convinced me 
that this kind of interface is appropriate for standardization, at least 
in the sense that, while broadly useful, using these services from a C++ 
application today requires difficult-to-get-right platform-specific 
code. Moving that burden to C++ library implementers, as a result, makes 
sense."


The former statement may be true, but the latter doesn't necessarily 
follow; and it isn't even clear that the former is true. The author 
himself demonstrates a prototype implementation that supports multiple 
platforms. And the Chromium Embedded Framework (CEF) has similarly long 
provided a cross-platform API for embedding the web into C++ applications.


Don't such third-party libraries show that it *is* possible to use the 
web in a C++ application without "difficult-to-get-right 
platform-specific code"?


(It might be that developing such a cross-platform library is itself 
challenging, but that's a burden on library vendors, not application 
developers.)


Cross-platform graphical application development with C++ can be 
challenging, and the web may be a solution in some cases. Indeed, 
Mozilla itself has faced that challenge and used its own web 
implementation to help solve it for desktop platforms. And others have 
solved it via third-party libraries and system-specific APIs.


Nevertheless, while those implementations are imperfect, and there's 
plenty of scope for improvement, a minimal standard that evolves more 
slowly than the web and its implementations seems like it would do more 
harm than good. And thus a web_view class isn't well-suited for 
specification by the C++ standards committee.


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Major preference service architecture changes inbound

[Myk Melez]

Nicholas Nethercote wrote on 2018-07-17 21:23:

This is a good example of how prefs is a far more general mechanism than I
would like, leading to all manner of use and abuse. "All I want is a
key-value store, with fast multi-threaded access, where the keys aren't
known ahead of time."
Agreed, the prefs service has been overloaded for too long due to the 
lack of alternatives for storing key-value data.


I've been investigating the Lightning Memory-Mapped Database (LMDB) 
storage engine for such use cases. It supports multi-threaded (and 
multi-process) access and is optimized for fast reads of arbitrary keys.


It could conceivably handle this subset of prefs usage, along with a 
variety of other KV storage use cases that currently use JSONFile or 
other bespoke storage engines/formats.


Follow along in bug 1445451 
(https://bugzilla.mozilla.org/show_bug.cgi?id=1445451) for status 
updates on validating, landing, and using LMDB (via the rkv Rust crate).


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

modifying vendored Rust crates locally

[Myk Melez]

With the fixes for bug 1323557 [1] and cargo-vendor issue #71 [2], it's 
now more straightforward to modify a vendored Rust crate to test changes 
locally or on tryserver.


To do so, specify the crate's vendored path in the [patch.crates-io] 
section of the top-level Cargo.toml file. For example, to modify the 
"zip" crate, add this line to that section:


zip = { path = "third_party/rust/zip" }

Then run `mach vendor rust`, which will update Cargo.lock with the 
patched location of the crate:


$ mach vendor rust
  Adding zip v0.3.1 (file:///path/to/workdir/third_party/rust/zip)
Removing zip v0.3.1

You'll need the latest version of cargo-vendor, 0.1.14, which you can 
get via `cargo install --force cargo-vendor`.


-myk

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1323557
[2] https://github.com/alexcrichton/cargo-vendor/pull/71

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

[Myk Melez]

Bobby Holley 
2018 March 12 at 12:25
That's not how I'd define XPCOM - XPCOM existed before XPIDL/XPConnect (and
the name XPConnect means "connecting Javascript to XPCOM"). But quibbling
over the definition isn't really useful.
I was aware that XPCOM predated XPConnect (although I didn't realize 
that it predated XPIDL). Regardless, I agree that quibbling over the 
definition isn't useful. However, it's useful to understand our 
respective definitions, so we know what we're each talking about.



The main platform feature that XPConnect relies upon is the interface
inheritance hierarchy derived from nsISupports, including the
QueryInterface method to bounce between them. Specifically, objects must
implement an interface in that hierarchy to be reflected out-of-the-box by
XPConnect. However, there are lots of bits of C++ code that use
QueryInterface as well, which would be more work to change.
Do any of those bits of C++ code depend on a particular feature of 
XPCOM, or do they just happen to use it to access components whose 
interfaces would just as effectively (modulo the work required to 
convert them) be exposed as concrete native classes?



The nsISupports hierarchy doesn't really cost us anything per se, certainly
not enough to justify the gargantuan task of trying to rip it out. Using it
heavily for performance-critical things can be slow (virtual methods plus
any QI overhead), but we should just fix those callsites when they come up.
There's also a developer ergonomics issue, as Components/QueryInterface 
is more complex and cumbersome than other JS interfaces to native code 
(WebIDL, Node.js Addons, etc.). We've worked around that to some extent 
with Services.jsm and other hacks.



XPConnect's dependency on runtime component registration is limited to the
platform objects we've implemented in JS. If we get rid of those, that
dependency goes away.

There are quite a few of these, if this search is accurate:

https://searchfox.org/mozilla-central/search?q=component.*%5C.js=false=true=*.manifest

And some of them depend on JSMs. Although it isn't clear at first glance 
how significant those dependencies are, nor how much work it would be to 
replace them with C++ or Rust implementations.



XPCOM is a not-very-well-delineated hodgepodge of mostly-independent
things. We are free to modify or remove any pieces that are causing
problems, provided someone can demonstrate that it's worthwhile.
Worthiness is relative to both effort and timeframe. That is to say: if 
something would take a lot of work but would pay off in the long run, 
then it may be worth a long-term (1-3 year) project for a small number 
of engineers, even if it isn't worth a short-term effort that diverts a 
large number of them.


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

[Myk Melez]

Nicholas Nethercote 
2018 March 9 at 20:02

What's your definition of XPCOM?
This is basically what I'm asking Kris. I define it as the system that 
Firefox uses to make intra- and inter-language calls between C++ and JS 
via XPIDL and XPConnect. I'm interested in what else it provides that 
makes it so indispensable.



Look in xpcom/, there is a ton of stuff in
there that is unrelated to XPIDL...
Indeed, but that doesn't tell me how much of XPCOM would remain 
essential to Firefox if we no longer used XPIDL.


For example, XPCOM supports component registration and overriding at 
runtime. But it isn't clear that Firefox needs those features, now that 
it no longer supports XUL extensions (unless perhaps for system extensions).


And xpcom/ contains a ton of stuff, as you say. But it isn't clear how 
much of it is core to XPCOM and how much just happens to live in that 
directory.


I'm not playing the devil's advocate. I'm genuinely curious about the 
extent of XPCOM's feature set (and how well it aligns with Firefox's 
current requirements).


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

[Myk Melez]

Kris Maglione 
2018 March 8 at 16:22

Removing XPCOM entirely is not really a possibility. Removing 
XPConnect bindings entirely is... theoretically possible, but would be 
a monumental amount of work, and is not something I've heard anyone 
seriously suggest.
If we removed XPConnect bindings entirely and converted XPIDL interfaces 
used only by C++ into concrete native classes, then what else would 
continue to need XPCOM?


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

[Myk Melez]

Kris Maglione 
2018 March 8 at 15:06
At any rate, I don't expect us to convert anywhere near all of our 
XPIDL interfaces to WebIDL. A lot of them don't need to be exposed to 
JS at all. A lot of those should still go away, but they don't need 
WebIDL bindings, just concrete native classes. And a lot of the rest 
are little-enough used that I can't see anyone spending the effort on 
converting them.

Would that remain true if doing so would enable us to remove XPCOM entirely?

-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Overriding JS to allow for opening in a new tab?

[Myk Melez]

Andrew Overholt 
2017 October 25 at 09:41
Is there precedent for doing what a user intended which would be contrary
to what the site is attempting?
I recall some discussion about preventing sites from using transparent 
elements to block click event handling, in particular context click on 
an image to copy/save it. That might be bug 102695 - [EVENTTARG]Treat 
some transparent elements as "transparent to events" [1].


The other bug that comes to mind is 380637 - Should web pages be 
restricted from being able to override the browser's keyboard shortcuts? 
[2].


Neither of those bugs have been resolved, however, so it's unclear that 
they create precedent.


-myk

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=102695
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=380637

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Reviews for in-tree documentation

[Myk Melez]

Dustin Mitchell 
2017 October 19 at 10:21
I think we should question the assumption that writing
source-code-level documentation is a good activity for newcomers to
the codebase.

Documentation is usually best written by someone with a deep
understanding of what is being documented, not by someone new to the
project. And this documentation is developer-focused, meaning anyone
understanding its content deeply should generally be an experienced
developer.
Documentation may best be written by such developers, but it can be 
revised by anyone. And new developers seem even more likely to notice 
the inaccuracies in our docs that prevent them from successfully 
building Firefox and using its APIs.



At the most, I can see using a documentation edit as an exercise in
going through the patch / review / land process for a contributor who
I would then urge on to more substantive tasks (which may also involve
substantive doc updates).
I agree that it isn't worth optimizing the documentation process for 
documentation-only contributors. But it's worth optimizing for revisions 
by developers who don't have commit access.


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Myk Melez]

Myk Melez <mailto:m...@mykzilla.org>
2017 September 26 at 17:40

Kartikaya Gupta <mailto:kgu...@mozilla.com>
2017 September 26 at 08:49
So from the discussion here it sounds like using a full (i.e.
non-grafted) cinnabar repository "just works" for most people. It has
the problem of missing CVS history but it seems like people who need
that often can use searchfox and/or a gecko-dev branch in a cinnabar
repo to get it.
Yes, and can we also integrate CVS history into a full cinnabar 
repository like mozilla/gecko using Git's "replace" command.
I've now done this for mozilla/gecko, so if you clone/fetch that repo, 
then you'll get both a "central" branch and a "cvs" branch.


The "central" branch contains mozilla-central history, and I continue to 
sync it with upstream mozilla-central using cinnabar. The "cvs" branch 
contains the CVS history.


To integrate them (without modifying either history), fetch replacement 
refs:


git fetch origin 'refs/replace/*:refs/replace/*'

(Replace "origin" with the name of your mozilla/gecko remote, if it 
differs.)


Then common Git commands (diff, log, bisect, etc.) will behave as if the 
oldest commit in "central" (e18f9a3) is the newest commit in "cvs" 
(3ec464b), and you can use them to traverse the entire history of Gecko 
transparently.


I've also updated https://wiki.mozilla.org/GitHub/Gecko_Repositories to 
include this information.


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Unship: stream decoder for BinHex format

[Myk Melez]

Boris Zbarsky 
2017 October 17 at 07:45
Please double-check that this use case does not get broken, or 
condition the code to be mailnews-only or something.

Shouldn't the code rather move to comm-central if it's specific to mailnews?

-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Myk Melez]

Jeff Griffiths wrote:

1. do you prefer the existing behaviour or the new behaviour?

I prefer the new behavior.


2. if you prefer a value for this pref different than 50 or 100, what
is it? Why?
I prefer a value of 0 (i.e. truly infinite tabs, never scrolling), 
because I distinguish tabs by their positions as much as (if not more so 
than) their labels, and showing all tabs fixes their positions, making 
them much easier to find again and click on, even with only a hazy 
recollection of where they are.


(Tabs do move a bit as other tabs are added/removed, but this movement 
is much slighter than that induced by scrolling, and they still stay in 
the same area of the screen.)


Also, when I'm traversing to a far-away tab, especially when using 
keyboard shortcuts, showing all tabs enables me to "see ahead" and 
locate the target tab with my eyes in time to slow down and stop on it 
with my fingers. With scrolling tabs, however, when far-away tabs are 
offscreen, I tend to overshoot the target and have to backtrack.


Back when we introduced scrolling, I set the preference to minimize it. 
Then, when the preference stopped working, I learned to live with 
scrolling tabs. But I still find it cumbersome and would prefer to 
disable tab scrolling.


I recall that Aza Raskin made some similar points back when we 
introduced scrolling. I think this was his blog post on the subject:


http://www.azarask.in/blog/post/firefox_20_tabs_gone_wrong/


One aspect that I would like to stress about this change: most
existing Firefox users will never see it, because they are unlikely to
open m,ore than 10 tabs at any one time. So what we are really talking
about is a change that will trade being able to see more tabs vs being
able to read more text in each tab title.
I'm actually the common case most of the time. I don't hoard tabs, and I 
close all tabs (except a small set of pinned tabs) after each browsing 
"session", which lasts anywhere from a few minutes to a few hours (or on 
very rare occasions, days). So I don't usually have more than a handful 
of tabs open.


But occasionally I do research that prompts me to open 20-40 tabs and 
then jump back and forth between them (f.e. when shopping for a product 
for which there are many choices, or when investigating a complex 
technical issue in our products). And that's when the tab overflow 
behavior makes a difference.


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Myk Melez]

Kartikaya Gupta 
2017 September 26 at 08:49
So from the discussion here it sounds like using a full (i.e.
non-grafted) cinnabar repository "just works" for most people. It has
the problem of missing CVS history but it seems like people who need
that often can use searchfox and/or a gecko-dev branch in a cinnabar
repo to get it.
Yes, and can we also integrate CVS history into a full cinnabar 
repository like mozilla/gecko using Git's "replace" command.



And we have mozilla/gecko on github which is a cinnabar mirror.
However this mirror is not "officially" supported (i.e. it's updated
by Myk but not by Release Operations). It also doesn't seem to have
branches for inbound/autoland.
Right, mozilla/gecko is unofficial and synced by me. See wikimo's 
GitHub/Gecko_Repositories 
 for more details on 
the differences between mozilla/[gecko-dev|gecko-projects|gecko].


And indeed, it doesn't have branches for inbound nor autoland. Adding 
those would be trivial, if they're useful, although it isn't clear how 
useful they can be until cinnabar metadata is syncable (in cinnabar 0.5?).



So it seems to me that the next step is to have the operations team
take over ownership of the mozilla/gecko mirror. dhouse, do you know
what the process would be for that? I'm guessing this just involves
running a cinnabar conversion and pushing to github on a cron job, but
Myk can provide more details, assuming he agrees this is what we want
to do.
I would be happy for the operations team to take over syncing of the 
mozilla/gecko mirror. My process for doing so is trivial, effectively just:


git checkout central && git pull && git push upstream central:central

Where "central" is a local branch whose upstream branch is the 
branches/default/tip branch on the 
hg::https://hg.mozilla.org/mozilla-central remote (fetched with 
cinnabar), and "upstream" is the g...@github.com:mozilla/gecko.git remote.


There are some additional details to work out: whether to maintain the 
option to use mozilla/gecko as a hub for shared development on feature 
branches, whether to sync tags to the repo (which are synced differently 
in cinnabar 0.5), which additional repos to sync, etc. I'm happy to chat 
through those with someone as appropriate.



Eventually once cinnabar supports storing metadata in the repo
we'll want that pushed to the github repo as well.

Indeed!

-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Myk Melez]

Ehsan Akhgari 
2017 September 18 at 12:59
I think there is a way to have our cake and eat it too, which is 
enabling git-cinnabar to understand a custom mapping of SHA1 so that 
we can rewrite the history and have cinnabar be able to deal with that 
when it maps hg/git revisions to each other.
We might be able to use Git's replace command [1], which enables you to 
"graft" one history onto another without rewriting revision IDs, such 
that Git commands like log, bisect, and blame traverse the two histories 
as one.


To test this out, I created a new repository mykmelez/gecko-test [2]; 
imported CVS history into a branch called "cvs"; imported the "central" 
branch from mozilla/gecko [3] (which is synced with cinnabar); and 
replaced e18f9a37a98d, which is the initial (earliest) commit on the 
central branch, with 3ec464b55782, which is the tip (latest) commit on 
the cvs branch.


The resulting log, starting from a9d623d0878b (the third-earliest commit 
on central), still shows e18f9a37a98d but decorates it with the 
"(replaced)" label and displays its replacement's commit message, after 
which the next two commits (55d824018c96 and 62453dda752a) are from CVS 
history:



 git log --oneline --decorate a9d623d0878b

a9d623d0878b Bug 374866. Reftests for text-transform. r=dbaron
028d2077b626 Free the (distributed) Lizard! Automatic merge from CVS: 
Module mozilla: tag HG_REPO_INITIAL_IMPORT at 22 Mar 2007 10:30 PDT,
e18f9a37a98d (replaced) - update headers - remove pango workarounds - 
update wget files paths

55d824018c96 - updating headers
62453dda752a split out breakpad symbol build and upload into two config 
options, r=preed


Neither history is altered, as the replacement is stored as a ref (in 
refs/replace/), which most Git commands respect ("except those doing 
reachability traversal (prune, pack transfer and fsck)"). So the store 
still contains the original initial mozilla-central commit:



 git --no-replace-objects log --oneline --decorate e18f9a37a98d

e18f9a37a98d Set up .hgignore to ignore CVS files.

And removing the replacement ref reverts the "graft," returning the two 
histories to their original, disconnected state.


A downside of this approach is that the replacement ref isn't fetched by 
default. You need to fetch it manually after cloning the repo:


git fetch origin 'refs/replace/*:refs/replace/*'

But you only need to do that once. And if you don't do it, you still get 
a working clone with a central branch that is the equivalent of 
mozilla-central cloned with cinnabar, along with a branch containing the 
CVS history. You just don't get combined history.


The CVS history doesn't take much space either. A fresh clone of 
mozilla/gecko takes 4.9GB on my system, while a fresh clone of 
mykmelez/gecko-test takes 5.2GB (about the same as gecko-dev, which is 
5.3GB).


So this seems like a promising option for having our cake and eating it 
too. Although further investigation is warranted to ensure that it works 
well with the Git commands (and editor integrations) that developers use 
when traversing history.


-myk

[1] https://git-scm.com/book/en/v2/Git-Tools-Replace
[2] https://github.com/mykmelez/gecko-test
[3] https://github.com/mozilla/gecko

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Myk Melez]

Kartikaya Gupta 
2017 September 18 at 07:05
It seems to me that a lot of people are now assuming a cinnabar repo
is the canonical way for git users to develop on mozilla-central. If
we want to make this mozilla policy I don't really have objections,
but I think that if we do that, we should maintain a canonical git
repo that is built using cinnabar, rather than having everybody have
their own "grafted" version of a cinnabar repo. The problem with the
latter approach is that different people will have different SHAs for
the same upstream commit, thus making it much harder to share repos.
Note that there's a third option, which is for everyone to have their 
own non-grafted version of a cinnabar repo. If you clone mozilla-central 
using cinnabar, instead of grafting commits onto a gecko-dev clone, then 
that's what you get, since cinnabar revision ID conversion is 
deterministic (as I understand it, anyway).


Having said that, I agree that it's worth enabling developers to clone a 
canonical Git repo. I've been syncing mozilla/gecko using cinnabar for a 
while to experiment with ways of doing this. There've also been 
conversations about syncing new commits to mozilla/gecko-dev with 
cinnabar for a few years, although I don't know of any active efforts to 
do this.


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to require `mach try` for submitting to Try

[Myk Melez]

James Graham 
2017 September 18 at 02:56
5. Allows vanilla git and hg on the client side, but requires 
something complex, custom, and scary on the server side to allow 
pushing to either repo. Could be possible if we eliminate ~all manual 
pushes (i.e. everything goes via autoland), but cinnabar or similar is 
still there in the background.
If the Gecko repository that developers clone is synced with cinnabar 
(which is how I sync mozilla/gecko, and which folks've discussed doing 
with mozilla/gecko-dev for years), then the scary server-side thing 
could be a Git repository synced with cinnabar that forwards pushes to 
the current tryserver.


That's essentially the same amount of scariness as is currently the case 
(i.e. cinnabar), except, as ekr noted, it is only maintained on the 
server rather than on each individual developer's machine.


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Moving from xulrunner to firefox SDK

[Myk Melez]

Manish 
2017 September 6 at 05:32

Thanks Myk

But I am bit confuse here. If we go by this way

/path/to/firefox --app /path/to/application.ini.

First there may be a possibility that Firefox is not installed and if 
it is installed and someone updates the firefox to latest version and 
the max ver. defined under application.ini is the older one, then the 
application won't start and will through the version mismatch alert.
Yes, these are all drawbacks to reusing an existing installation of 
Firefox. In order to do so successfully, you would need to ensure that 
your users install (and retain) Firefox and keep your application 
up-to-date with new versions of the browser.


Isn't there any method or terms defined where I can ship the firefox 
directory in the application folder rather than re-brading it or 
should we by default set the max version in application.ini to a 
higher value i.e 99 or if you can suggest any other way.
If you set the maxVersion value in application.ini to an unreleased 
version of Firefox, such as 99, then you face the risk that your 
application will break with a new version of Firefox that isn't 
backward-compatible. A better option would be to test your application 
with each new version of Firefox and then update its maxVersion value 
accordingly.


However, the best option is perhaps to ship your application with its 
own copy of Firefox, as you've suggested. Technically, it's possible to 
do so. That's the idea behind the qbrt experiment 
 that I previously mentioned. I'm 
unfamiliar with the legal requirements for doing so, however.


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Moving from xulrunner to firefox SDK

[Myk Melez]

Manish 
2017 August 21 at 23:53
from where can I find the latest firefox SDK version for all the 
platforms eg: windows, linux and mac. Second can the directory 
structure remains the same as earlier like for xulrunner.
There isn't a Firefox SDK, as Mozilla decided to stop supporting the 
embedding use cases that were previously supported by XULRunner.


However, Firefox continues to ship a "private XULRunner" that other 
applications can access via its --app command-line flag, which means 
that you can run a XUL application on a system with Firefox via 
/path/to/firefox --app /path/to/application.ini.


That also means that you could technically repurpose a Firefox 
distribution to serve as your application's distribution by replacing 
its application.ini and other application/branding files with your 
application's files. The experimental qbrt project 
 does this.


Note that these approaches aren't officially supported. However, the 
--app flag has been present in Firefox for a long time, and I'm not 
aware of any plans to remove it.


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nodejs for extensions ?

[Myk Melez]

Enrico Weigelt, metux IT consult 
2017 July 28 at 21:33
Hi folks,


just curious: did anyone already try nodejs modules
for (javascript-only) extensions ?
There was some discussion of this in the dev-addons thread "Node and Web 
Extensions Experiment" 
. 
We also discussed a related idea in the firefox-dev thread "SpiderNode 
for Firefox chrome code" 
.


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Embedding Firefox or Gecko in 2017

[Myk Melez]

cnico7 
2017 July 6 at 12:47
I had the idea of using firefox with marionette protocol in order to 
interact with the engine and to use a custom plugin in order to hide 
all the design (menus, tab bars,...). This idea has many drawbacks : 
it is slow at launching time, it requires to improve marionette 
protocol in order to intercept browsing events and hiding all ui 
elements with webextensions is no more possible.

So my idea is clearly not a the good way.
You don't need to use a plugin or extension to customize Firefox's 
chrome, as you can use Firefox as a runtime to load a custom XUL 
application that exposes any chrome you want (including none at all).


You just need to start Firefox with a -app flag pointing to a directory 
containing a XUL application. See qbrt  
for an example of a project that uses Firefox as a XUL runtime.


As Henri noted about Positron, this isn't embedding; but it may be 
sufficient to meet your needs. And it wouldn't require you to 
use/improve the Marionette protocol, as your application could interact 
with the custom XUL application using pipes, HTTP, or any other 
available mechanism for IPC (some of which may require you to compile a 
custom build of Firefox).


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: ANN: Default bug view for BMO changed today!

[Myk Melez]

> Mike Hommey 
> 2017 March 1 at 14:50
> 1. I often wish browsers were helpful here. Seriously. When an anchor is
> close enough to the end of the page that the page can't be scrolled for
> it to be at the top of the viewport, it's a PITA to find where it is.
Indeed. I thought I recalled reading a particular comment about why this
is hard to resolve, but I don't find that one now, only a bunch of
discussion in a variety of interrelated bugs:

https://bugzilla.mozilla.org/show_bug.cgi?id=735614
https://bugzilla.mozilla.org/show_bug.cgi?id=269172
https://bugzilla.mozilla.org/show_bug.cgi?id=68402

-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Embeddable Browser

[Myk Melez]

Rodolpho Porto <mailto:rodolpho.po...@gmail.com>
2017 February 22 at 03:13

Hello Myk Melez,

First of all, thank you for your response!

I'll talk about the project, it's a kiosk-style browser, using 
XULRunner 24.0b10 32bit and SWT, the modifications we made were 
according to project needs and security requirements. All of this is 
in the testing phase, but the project is still evolving, the project 
is huge and XulRunner's share is small but of paramount importance.
If your project is a XUL app, then you should be able to compile Firefox 
with the modifications you made to XULRunner and then use Firefox in 
place of the XULRunner runtime to run the app via Firefox's --app 
command-line flag.


But from your description, I wonder if it's actually a native app that 
you're linking against libxul from the XULRunner SDK. Is that correct? 
And is your code open source and available for browsing online by any 
chance?


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

fixing bug 1190128 (was Re: Is there a reason for scrapping native.js?)

[Myk Melez]

Sergey Rozhenko 
2017 January 29 at 08:34
I've fixed https://bugzilla.mozilla.org/show_bug.cgi?id=1190128 in an 
addon because noone has ever looked at that bug

Hi Sergey,

Is there a reason why you haven't contributed your fix for that bug to 
Firefox? Bugs do sometimes get overlooked, but patches with a review 
request are almost always reviewed. It's of course fine to fix a bug in 
an addon, especially if you think that your fix is one that Firefox 
won't take. At first glance, however, I don't see any reason why Firefox 
wouldn't take a fix for that bug.


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: What if you could reinvent Firefox theming?

[Myk Melez]

Justin Dolske 
2016 September 8 at 15:41
"Make things bigger" is somewhat curious... On Windows this is typically
done by adjusting the display scaling factor in the OS settings. I wonder
if people don't know about that, or are looking to make Firefox --
specifically -- larger than normal. I'm unclear on what Linux offers these
days, and while I think OS X supports this internally it's not exposed in
any UI. (Apple's preferred route seems to be screen zooming. Which is neat,
I use it all the time and have normal vision.) So I'd be curious to
understand this use-case better.
I suspect that users indeed are unaware that they can fix this in OS 
settings (except on Mac), and if an OS vendor asked the same questions 
about the system as a whole, they'd get a similar response. It'd be 
interesting for us to confirm that with a followup question about 
Firefox vs. apps in general.


For my part, I too have "normal" (i.e. emmetropic) vision too (although 
lately with a bit of presbyopia). Nevertheless, I've long found native 
UI affordances to be too small. In the past, I've decreased the 
resolution of my display or installed themes with larger icons (in apps 
that support themes) to mitigate the issue. These days I mostly just 
live with it for native apps. But I almost always zoom web apps.


Although it's dangerous to extrapolate from a sample of two (especially 
us two!) I suspect we aren't isolated cases, and there's a population of 
folks with "normal" vision who nonetheless prefer larger affordances for 
better readability, easier click targets, etc. and are willing to trade 
off space for content or other windows (or, in your case, to use 
features like screen zooming).



Separately from themes, I think it would be a good idea to consider adding
preferences UI for the default zoom-level of page content in Firefox.
Indeed. Another interesting (but more complex to implement) option would 
be to adjust that zoom level to maximize the horizontal usage of space 
of a page, zooming more for sites with small font sizes and narrow 
columns of content, and less for sites where the default zoom level 
pushes content offscreen and creates horizontal scrollbars (or triggers 
an over-responsive mobile-friendly rearranging of content).


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Two Factor Authentication and Github

[Myk Melez]

Rok Garbas 
2016 May 24 at 01:50
you can also setup github's 2fa using GAuth[1] firefox app

Or use Firekey in any web browser:

https://firekey.org/

-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HTML-based chrome and

[Myk Melez]

Benjamin Francis 
2016 February 26 at 10:16

I like this idea in theory. But I want to understand how it's different
from Electron, besides simply using different underlying technology. In
other words: what makes it unique that justifies the effort?

Why does it even have to be unique? Being able to build a browser using a
browser engine seems like table stakes to me...
There's a significant difference between the minimal effort currently 
required to make Gecko embeddable (at a high cost per embedding) and the 
larger, ongoing effort that would be required to build and maintain an 
application development platform like Electron.


Moreover, there's an opportunity cost: time spent developing that 
platform would be time not spent enhancing Gecko's Web platform 
implementation.


Nevertheless, the more significant factor is that this would be a 
cultural sea change in the Gecko project. Even with engineers who were 
willing and able to sign up to do the work (and who would otherwise not 
hack on Gecko, minimizing the opportunity cost), it would still be a 
challenge to make Gecko-as-platform a fundamental part of the way Gecko 
is developed. The small matter of programming is the least of our concerns.


Which doesn't mean I think it's a bad idea. To the contrary, a 
successful app platform based on Gecko would indirectly benefit Gecko's 
Web platform goals (and Firefox) by expanding the community of 
contributors to the project. But an unsuccessful effort would do more 
harm than good.


So I still want to understand how "Gecktron" would be different, and why 
a developer (Mozillian or otherwise) should prefer it to Electron. Why 
not use Electron for your project?


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HTML-based chrome and

[Myk Melez]

Benjamin Francis 
2016 February 26 at 05:15
I mainly propose the change of syntax because this transition period seems
like an opportunity to make a clean break, get rid of the vendor prefixes
and define a long term, explicitly separate to standard HTML, chrome-only
solution with a cleaner API and without having to worry about backwards
compatibility because the mozBrowser API could exist in parallel until we
phase it out.
I'd like to see this too, if only because  is more ergonomic 
and easier to distinguish from the existing  API. 
However, the isolated  from bug 1238160 is reasonable 
and a great start.



But I think a more important piece than webview is the ability to execute a
Gecko-based user agent with HTML-based chrome without having to run it on
top of the Firefox binary.
I like this idea in theory. But I want to understand how it's different 
from Electron, besides simply using different underlying technology. In 
other words: what makes it unique that justifies the effort? Is there 
something that Gecko can provide that Chromium cannot (or is unlikely 
to)? Are there parts of the Electron stack that are encumbered in some 
way? Are there architectural choices that make Electron unsuitable or 
suboptimal for valuable use cases?


(You can argue that developers having two options is by itself 
beneficial. And I agree, in general. But I'm not yet convinced that we 
should therefore invest the effort to build the second option.)



If we no longer have XULRunner, if mozApps is
phased out and B2G loses platform support we're really running out of
options for how to use Gecko for non-Firefox projects. At what point does
the platform stop being a platform and just becomes Firefox?
That point is well in the past, as Gecko development post-Netscape has 
focused on the Web platform and integration with Firefox.  Other uses, 
like XULRunner and embedding in native apps, have been second-class 
citizens, at best.



How are we
promoting innovation if we're effectively forcing alternative user agents
to use WebKit?
Mozilla's mission is to promote "openness, innovation & opportunity on 
the Web."  Mitchell clarified in 2007 that Mozilla's key platform is the 
Open Web 
.


I happen to think that making Gecko a great platform for building 
products like (but not limited to) Firefox indirectly benefits that 
mission. But doing so would still be in service to that mission, a way 
to help fulfill it, and not the actual mission itself.


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HTML-based chrome and

[Myk Melez]

Ehsan Akhgari 
2016 February 25 at 11:14
mozApps and the browser API are orthogonal for the most part.  Removing
mozApps doesn't mean that we would remove the mozbrowser API (and AFAIK
that's not what Myk is planning.)

Confirmed: I'm definitely *not* planning to remove the mozbrowser API!

-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HTML-based chrome and

[Myk Melez]

Benjamin Francis 
2016 February 25 at 07:18
With the demise of XULRunner it seems the only way to run a Gecko-based
project that isn't Firefox is to run it on top of Firefox. That doesn't do
much to "promote innovation" and I'm guessing is a major reason projects
like Brave are being forced to switch to Webkit/Electron.
I expect that's true in general, although for Brave in particular, 
Brendan tweeted, "Started w/ Graphene/Gecko but needed full sandboxing, 
MDI,  Also: Chrome web compat :-(." 
. And the 
Brave FAQ states, "We did a careful head-to-head comparison and by every 
measure, Electron/chromium won" .


So the relative support for embedding doesn't appear to be the major driver.

-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Making it easier to file performance bugs?

[Myk Melez]

David Rajchenbach-Teller 
2016 February 13 at 04:50
One possible solution would be to:
- add a component Firefox > Performance (and also Thunderbird >
Performance, etc.) to Bugzilla, which would cover all untriaged
performance issues (including web content, ux, e10s, ...);
- have people triaging these issues to likely features involved.
I'd explore a solution along the lines of webcompat.com, which 
drastically reduces the barrier to entry for both BMO novices and 
experts. Besides dreamy UX, it offers anonymous reporting, so you don't 
need to authenticate. And it elides the distinction between a browser 
and a website issue, so users don't have to figure out the locus of the 
issue before reporting it. (Of course many users don't do this anyway; 
but the requirement that they do so is a barrier to entry in itself.)


With webcompat.com, the process is just as important as the technology: 
having folks to triage incoming reports, file bugs in product-specific 
trackers like BMO, and update those reports (which are stored as issues 
in GitHub) with changes to the underlying bugs is critical. Which is 
similar to your proposal.


Unlike your proposal, webcompat.com's scope is broader than Firefox, 
since it welcomes issues in sites themselves, and it also addresses 
issues in other browsers. But a narrower focus on Firefox perf would 
still benefit from the streamlined process that it exposes to reporters.


And it's worth considering broadening the scope anyway, since some perf 
problems will be website issues that nevertheless affect Firefox users' 
experience. If I had had a simple way to do so, I might have reported a 
slow interaction on mint.com in Firefox (but not Chrome) that I used to 
experience and suspected was an issue with the website itself.


For an example of an issue that went through the webcompat.com process 
(and turned out to be a dupe), see 
, which I filed a few 
days ago and miketaylr triaged/duped.


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Possible psutil bustage

[Myk Melez]

On 2013/08/23 10:28, Gregory Szorc wrote:

The following should get your tree in a happy state:

$ hg status -in python/psutil | xargs rm

If your tree is a Git mirror clone, an equivalent is:

   git clean -xf python/psutil


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [b2g] Fix or disable windows desktop b2g builds

[Myk Melez]

On 2013/06/07 12:39, Chris AtLee wrote:
It's my understanding that the FxOS Simulator doesn't directly depend 
on these builds. Can anybody confirm this?
I can confirm it, since I build B2G Desktop for the FxOS Simulator, and 
I don't depend on these builds.


However, I build on the b2g18 branch, and at some point we'll want to 
switch to the master branch (or some newer long-lived branch) or build 
versions of the Simulator for both branches, at which point this issue 
may crop up again.


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [b2g] Fix or disable windows desktop b2g builds

[Myk Melez]

On 2013/06/06 20:50, Tim Chien wrote:

I suggest the Apps team should aware of this and potentially invest
some resource into the Windows build, if we want to fully support FxOS
Simulator as a product.
At least some of us on Apps are aware of it, and we've already invested 
some resources into the Windows build, which is part of the reason it 
works to some extent.


But if we do want to fully support the Simulator as a product, and the 
we in question is the Mozilla organization (which it should be for a 
fully-supported product), then it's worth involving other teams too, if 
they're better equipped to address particular issues, like the Platform 
team for platform problems and RelEng for build system bugs.


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform