Re: Do we have some documents listing up when we need to touch CLOBBER?

[Masayuki Nakano]

On 2016/12/16 19:53, Mike Hommey wrote:

On Fri, Dec 16, 2016 at 05:16:25PM +0900, Masayuki Nakano wrote:

Hi,

I'm looking for some documents which explain when we need to touch CLOBBER
to avoid build failure. However, I've not found such document yet. I see
such information only in CLOBBER about WebIDL change.

So, is there any document which lists up when we need to touch CLOBBER?


The rule is that CLOBBER should never need to be touched. Unfortunately,
our build system is far from perfect, and there are plenty of cases
where that doesn't actually hold true. There are a bunch of bugs filed
for those cases, and new ones should be filed and marked as blocking bug
#941904. IOW, the dependencies of bug #941904 that are still open are
the currently known cases where a CLOBBER was required, but many of them
are of the form "bug # required a clobber".

Mike



Thank you for the information! That fixes my concern. I thought that 
platform developers need to touch CLOBBER at writing patches by themselves.


So, not necessary us to touch CLOBBER really helps me.

--
Masayuki Nakano 
Manager, Internationalization, Mozilla Japan.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Do we have some documents listing up when we need to touch CLOBBER?

[Masayuki Nakano]

Oh, do you mean that nobody doesn't have concrete scenarios when 
developers need to touch CLOBBER?


When not touching CLOBBER causes build failure at autoland, will it be 
fixed by a follow up landing which touches CLOBBER or backed out and 
need to reland same patches with touching CLOBBER?


If it's the latter, there should be listed up the scenarios in MDN or 
somewhere. (Although, even if it's the former, such document must be 
helpful for anybody work on managing the tree.)


On 2016/12/17 2:22, Benoit Girard wrote:

One of my goal when introducing CLOBBER was to document what was causing us
to CLOBBER so that we could audit and fix them if we ever found the time.
You can get a pretty good idea by going through the history of the file.

I don't believe anyone has taken to time to go through the CLOBBER hg
history to find the causes and document them. That could be interesting.

On Fri, Dec 16, 2016 at 12:16 AM, Masayuki Nakano 
wrote:


Hi,

I'm looking for some documents which explain when we need to touch CLOBBER
to avoid build failure. However, I've not found such document yet. I see
such information only in CLOBBER about WebIDL change.

So, is there any document which lists up when we need to touch CLOBBER?

--
Masayuki Nakano 
Manager, Internationalization, Mozilla Japan.
___
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




--
Masayuki Nakano 
Manager, Internationalization, Mozilla Japan.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Who loves multiple selection feature in editor?

[Ehsan Akhgari]

On 2016-12-15 4:46 AM, Masayuki Nakano wrote:
> At investigating selection API behavior, I realized that non-Gecko
> engines don't support multiple selection.
> 
> For example, document.getSelection().addRange(somethingNewRange) does
> nothing when the selection has a range.
> 
> You can see the behavior with following testcases:
> 1. in editable content: https://jsfiddle.net/d_toybox/9Lrs62po/3/
> 2. in static content: https://jsfiddle.net/d_toybox/9Lrs62po/2/
> 
> Personally, I like the multiple selection feature when I copy a lot of
> fragments of a document. However, who needs this feature in editor?
> Supporting multiple selection in editor makes our editor code
> complicated. For example, when web apps try to make the text content
> bold, editor needs to do it at every selection range. If selection is
> modified during handling something, loop for selection ranges may cause
> crash (I've seen a lot of similar crash bugs).
> 
> So, it might be better to stop supporting multiple selection only in
> editor if the feature is not so loved by users.
> 
> I filed a bug for discussing this issue here:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1323681

We currently expose selections with multiple ranges at several levels:

* The developer facing APIs.  As you have noted above, our selection API
allows you to construct and examine multi-range selections.  This is
something that we should fix at some point, since other browser vendors
have been very clear that they won't implement this functionality (and I
think that's a good idea) so we're not interoperable with them on this
front.

* The user facing functionality.  Currently we expose multi-range
selections to the user in the following ways (perhaps among others that
I'm missing?):

  * Table cell selection (by Ctrl/Cmd-clicking on several table cells
allows you to select them all)
  * Mouse based selection (by holding Ctrl/Cmd when selecting something
on a page with another selection present)
  * (and perhaps touch based selection also similarly, but I don't have
a device I can test that on)

There is at least one good use case for this, which is copying things to
the clipboard, but if we decide to keep the user facing functionality,
then we should determine what to expose to developers when a multi-range
selection is made by users.  There are several options, such as only
representing the first selection in the range, or the latest (last) one.

(I also wonder how many people even know about these ways to create
multi-range selections, given how undiscoverable they are!  We should
probably add telemetry to measure their usage.)

* The interactions with the editor, which I definitely agree is a mess.
I'm not sure what you specifically mean by not supporting them.  Given
that they are currently possible to create by the user, we need to
handle them _somehow_ in the editor code.  I personally think we should
drop support for user made multi-range selections over editable regions
to guarantee that the editor code never actually hits this case...

* Gecko's internal usage of multi-range selections.  We use multi-range
selections to implement some other selection types, including spellcheck
(which we use to mark the misspelled areas to be drawn with the red
squiggly line) and find (which we use to mark highlighted areas as the
result of using the find bar, which can create a multi-range selection
when using the Highlight All mode.)  Clearly we can't drop support for
what we need to deal with spellcheck selections which are often
multi-range.  Have you considered this in your plans?

I think we should probably ask other browser vendors about this again so
that we can plan our future here better.

Cheers,
Ehsan

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

Re: Intent to ship: NetworkInformation

[Ralph Giles]

On Fri, Dec 16, 2016 at 12:25 PM, Jason Duell  wrote:

> So a switch that toggles the "network is expensive" bit, plus turns off
> browser updates, phishing list fetches, etc?

Windows 10 has such a switch, although I suspect it's up to
applications to opt-in. An API to query 'metered connection' status
for each interface has been available since Windows 8. See
https://msdn.microsoft.com/en-us/library/windows/desktop/hh437593(v=vs.85).aspx

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

Re: Intent to ship: NetworkInformation

[Jason Duell]

On Fri, Dec 16, 2016 at 11:35 AM, Tantek Çelik 
wrote:

>
> Honestly this is starting to sound more and more like a need for a
> "Minimal Network" variant of the "Work Offline" option we have in
> Firefox (which AFAIK no other current browser has), since no amount of
> OS-level guess-work is going to give you a reliable answer (as this
> thread has documented).
>

So a switch that toggles the "network is expensive" bit, plus turns off
browser updates, phishing list fetches, etc?  I can see how this would be
nice for power users on a tethered cell phone network.  One issue would be
to make sure users don't forget to turn it off (and never update their
browser again, etc).  Maybe it could time out.

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

Re: Intent to ship: NetworkInformation

[Tantek Çelik]

On Fri, Dec 16, 2016 at 10:51 AM, Gervase Markham  wrote:
> On 15/12/16 14:20, Daniel Stenberg wrote:
>> Looking at that collection of existing user, basically all of them want
>> the user to anser this question:
>>
>>  "Use expensive traffic (y/n)"
>
> And this should be an OS-level switch which the browser and other apps
> both respect and reflect. Doesn't Android already have a "background
> data" switch?

Until an OS-level switch happens, I think a browser level switch could
work well.


> If I'm on the train wifi, I want to turn off all unnecessary traffic,
> both to show love to other users, and because it'll make what I'm
> actually focussed on doing faster. Now is not the time to run a backup.
> I'd love such a switch on my laptop which my apps and web pages respected.

Gerv points out another good use-case. Train/plane and other shared
limited wifi.

Honestly this is starting to sound more and more like a need for a
"Minimal Network" variant of the "Work Offline" option we have in
Firefox (which AFAIK no other current browser has), since no amount of
OS-level guess-work is going to give you a reliable answer (as this
thread has documented).

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

Re: Intent to ship: NetworkInformation

[Gervase Markham]

On 15/12/16 14:20, Daniel Stenberg wrote:
> Looking at that collection of existing user, basically all of them want
> the user to anser this question:
> 
>  "Use expensive traffic (y/n)"

And this should be an OS-level switch which the browser and other apps
both respect and reflect. Doesn't Android already have a "background
data" switch?

If I'm on the train wifi, I want to turn off all unnecessary traffic,
both to show love to other users, and because it'll make what I'm
actually focussed on doing faster. Now is not the time to run a backup.
I'd love such a switch on my laptop which my apps and web pages respected.

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

Re: Do we have some documents listing up when we need to touch CLOBBER?

[Boris Zbarsky]

On 12/16/16 3:16 AM, Masayuki Nakano wrote:

I see such information only in CLOBBER about WebIDL change.


This is specifically about 
https://bugzilla.mozilla.org/show_bug.cgi?id=1103153 or something else?


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

Re: Rust required to build Gecko

[Ralph Giles]

Anyway, thanks for the suggestion, Simon. I filed
https://bugzil.la/1324040 with this fix.

In the meantime, the curl command line from https://rustup.rs/ should
work equivalently.

 -r

On Fri, Dec 16, 2016 at 9:40 AM, Ralph Giles  wrote:
> On Fri, Dec 16, 2016 at 9:19 AM, Simon Sapin  wrote:
>
>> RUSTUP_URL_BASE = 'https://static-rust-lang-org.s3.amazonaws.com/rustup'
>>
>> If that fixes the issue for you, it’s likely that your Python version does
>> not support SSL SNI.
>
> I can reproduce with python urlib2.urlopen() on an ubuntu 14.04 docker
> container. I thought using the in-tree requests module to work around
> that issue?
>
>  -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rust required to build Gecko

[Ralph Giles]

On Fri, Dec 16, 2016 at 9:19 AM, Simon Sapin  wrote:

> RUSTUP_URL_BASE = 'https://static-rust-lang-org.s3.amazonaws.com/rustup'
>
> If that fixes the issue for you, it’s likely that your Python version does
> not support SSL SNI.

I can reproduce with python urlib2.urlopen() on an ubuntu 14.04 docker
container. I thought using the in-tree requests module to work around
that issue?

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

Re: Do we have some documents listing up when we need to touch CLOBBER?

[Benoit Girard]

One of my goal when introducing CLOBBER was to document what was causing us
to CLOBBER so that we could audit and fix them if we ever found the time.
You can get a pretty good idea by going through the history of the file.

I don't believe anyone has taken to time to go through the CLOBBER hg
history to find the causes and document them. That could be interesting.

On Fri, Dec 16, 2016 at 12:16 AM, Masayuki Nakano 
wrote:

> Hi,
>
> I'm looking for some documents which explain when we need to touch CLOBBER
> to avoid build failure. However, I've not found such document yet. I see
> such information only in CLOBBER about WebIDL change.
>
> So, is there any document which lists up when we need to touch CLOBBER?
>
> --
> Masayuki Nakano 
> Manager, Internationalization, Mozilla Japan.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rust required to build Gecko

[Simon Sapin]

On 16/12/16 17:27, Ben Kelly wrote:

I tried ./mach bootstrap on a fresh m-c this morning and got:

Will try to install Rust.
Downloading rustup-init... Error running mach:

['bootstrap']

The error occurred in code that was called by the mach command. This is
either
a bug in the called code itself or in the way that mach is calling it.

You should consider filing a bug for this issue.

If filing a bug, please include the full output of mach, including this
error
message.

The details of the failure are as follows:

URLError: 


What Python version do you have? (Run 'python --version') If it’s not 
the latest, can you update it?


Try modifying python/mozboot/mozboot/rust.py to replace this line:

RUSTUP_URL_BASE = 'https://static.rust-lang.org/rustup'

by this line:

RUSTUP_URL_BASE = 
'https://static-rust-lang-org.s3.amazonaws.com/rustup'


If that fixes the issue for you, it’s likely that your Python version 
does not support SSL SNI.


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

Re: Intent to ship: NetworkInformation

[Ehsan Akhgari]

On 2016-12-15 6:28 PM, Boris Zbarsky wrote:
> On 12/15/16 6:15 PM, Ehsan Akhgari wrote:
>> (I personally agree with most of what you said, except that I'm
>> convinced that we should expose that one bit.)
> 
> Exposing this one bit makes a lot of sense to me.
> 
>> From a more practical perspective, we have two shipping implementations
>> of this API.  What are you proposing to do with that for starters?
> 
> After we finish crying?  I think we fundamentally have two options:
> 
> 1)  Create a new API, convince everyone to ship it and deprecate the
> other thing, and eventually hopefully remove it.

CCing Marcos, as he may have an idea about the practicality of this
approach.

> 2)  Figure out a way to map the one bit of information we actually want
> to expose into some sort of values that look like the existing API.
> Change the spec as needed to allow tweaks we want to make here (e.g. to
> allow having the max speed thing not be defined or always be 0 or always
> +Infinity, or always NaN, or always 42 or something).

This would be interesting to think about...

Would it be safe to conclude that at this point we should not be
exposing this API to more contexts (such as workers, and/or non-Android
platforms)?

>> Note that Chrome has some use counters on this API:
> 
> Right, those are all above their removal thresholds.  But I should note
> that we've recently removed other things with high use counters once we
> determined that a lot of that was from tracking scripts...  That said,
> the NetInfoOnChange counter is not likely to be tracking script.

Right.

> I assume this is just data from Chrome, not webviews?

Honestly I don't know.  The UseCounter code I've seen in Blink seems to
collect counters unconditionally, but they may very well filter out data
from webviews somewhere in their pipeline.

We should probably consider collecting our own telemetry for this.

> -Boris
> 
> P.S.  I wish our DOM counters had a display like this, both in terms of
> searchability and performance.  :(

Amen to that...  :/

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

Re: Rust required to build Gecko

[Ben Kelly]

I tried ./mach bootstrap on a fresh m-c this morning and got:

Will try to install Rust.
Downloading rustup-init... Error running mach:

['bootstrap']

The error occurred in code that was called by the mach command. This is
either
a bug in the called code itself or in the way that mach is calling it.

You should consider filing a bug for this issue.

If filing a bug, please include the full output of mach, including this
error
message.

The details of the failure are as follows:

URLError: 


On Thu, Dec 15, 2016 at 7:28 PM, Ralph Giles  wrote:

> Today we've pushed the change to enable rust language code by default
> in Firefox builds. The changes are on the autoland branch right now,
> so this will affect your builds from mozilla-central or gecko-dev
> starting tomorrow. This brings our default developer build in line
> with what we've been doing with official builds. Thanks to everyone
> who helped make this happen.
>
> As a reminder, you'll now need `rustc` and `cargo` in the PATH of your
> build environment, just like with python and the C/C++ compiler. You
> can install rust with `./mach bootstrap`. After that you can stay on
> the latest stable release by running `rustup update` every 6 weeks or
> so. If you want more control I recommend manually running the
> installer and update tool from https://rustup.rs/
>
> More information about using Rust code in Firefox can be found at
> https://developer.mozilla.org/en-US/Firefox/Building_
> Firefox_with_Rust_code
>
> Cheers,
>  -r
>
>
> On Thu, Nov 24, 2016 at 2:49 PM, Ralph Giles  wrote:
> > tl;dr This is a heads-up that all gecko developers should install rust.
> >
> > Next week I plan to switch our default build config to require Rust
> > when building Firefox.[1] If you compile Firefox from the C++ source,
> > please install the Rust language environment now.
> >
> > You can install Rust by running `./mach bootstrap` which will download
> > and run the rustup installer for you.[2]
> >
> > We recommend the installer at https://rustup.rs/ (despite being beta)
> > because it makes staying up to date and cross-compilation easy. If you
> > want more control, or to experiment with rust, you can install
> > directly from that website.
> >
> > The main thing is to have up-to-date versions of the `rustc` and
> > `cargo` executables in the path of your build shell. Rust releases
> > every six weeks, just like Firefox, and we generally require the
> > latest stable release to compile mozilla-central. You can stay current
> > by running `rustup update`.
> >
> > You'll still be able to build without a rust compiler by adding:
> >
> >   ac_add_options --disable-rust
> >
> > to your mozconfig. This is a temporary work-around; we expect to
> > remove that option and require Rust unconditionally early next year as
> > non-optional features start to depend on it.
> >
> > Rust language in Gecko is an important part of Project Quantum. I'm
> > excited to be taking this next step toward that future. We first
> > shipped Rust code to users in Firefox 48, so it's long past time this
> > aspect of our default builds matched what we release.[3]
> >
> > Thanks for your attention,
> >  -r
> >
> > [1] Enabling rust is https://bugzil.la/1283898
> > [2] bootstrap support landed Tuesday in https://bugzil.la/1286799
> > [3] If you have issues with the installer or build, please file issues
> > blocking our tracking bug at https://bugzil.la/oxidation
>
> --
> You received this message because you are subscribed to the Google Groups
> "gecko-all" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to gecko-all+unsubscr...@mozilla.com.
> To post to this group, send email to gecko-...@mozilla.com.
> To view this discussion on the web visit https://groups.google.com/a/
> mozilla.com/d/msgid/gecko-all/CA%2Brf4XK6cuhDPk%
> 2B39o6SLgRpCZ9z%3DepgugEzpuB_SW0hJ05a8w%40mail.gmail.com.
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: BeforeAftereKeyboardEvent

[smaug]

On 12/16/2016 10:36 AM, Masayuki Nakano wrote:

Due to the end of B2G platform, I'd like to remove mozbrowserbeforekeydown, 
mozbrowserbeforekeyup, mozbrowserafterkeydown and mozbrowserafterkeyup
events and its event classes.

They were implemented by bug 989198 [1] for allowing embedded browser elements 
to override keyboard events [2]. These events have never been enabled
on non-B2G platforms but they make the keyboard event propagation complicated 
especially in PresShell.

I'm working on this in bug 1322736 [3].

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=989198
[2] 
https://wiki.mozilla.org/WebAPI/BrowserAPI/KeyboardEvent#Dispatch_KeyboardEvent_across_BrowserElements
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1322736




Sounds good.



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

Intent to unship: BeforeAftereKeyboardEvent

[Masayuki Nakano]

Due to the end of B2G platform, I'd like to remove 
mozbrowserbeforekeydown, mozbrowserbeforekeyup, mozbrowserafterkeydown 
and mozbrowserafterkeyup events and its event classes.


They were implemented by bug 989198 [1] for allowing embedded browser 
elements to override keyboard events [2]. These events have never been 
enabled on non-B2G platforms but they make the keyboard event 
propagation complicated especially in PresShell.


I'm working on this in bug 1322736 [3].

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=989198
[2] 
https://wiki.mozilla.org/WebAPI/BrowserAPI/KeyboardEvent#Dispatch_KeyboardEvent_across_BrowserElements

[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1322736

--
Masayuki Nakano 
Manager, Internationalization, Mozilla Japan.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Do we have some documents listing up when we need to touch CLOBBER?

[Masayuki Nakano]

Hi,

I'm looking for some documents which explain when we need to touch 
CLOBBER to avoid build failure. However, I've not found such document 
yet. I see such information only in CLOBBER about WebIDL change.


So, is there any document which lists up when we need to touch CLOBBER?

--
Masayuki Nakano 
Manager, Internationalization, Mozilla Japan.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform