Re: Intent to ship: NetworkInformation

[mcaceres]

On Saturday, December 17, 2016 at 3:38:45 AM UTC+11, Ehsan Akhgari wrote:
> 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.

I don't know tbh...  given that there has been no agreement about this since 
2011 (it's definitely the most controversial API I've ever been involved with - 
and I only got involved when we moved it to the WICG). We can definitely try to 
improve the current one - and learn from what Google shipped (by talking to 
them and see if we can find out a bit more about who is using it and how). I 
think Facebook was using it to not load video for ads when the connection is 
2G, for example. 

If other people want to have a go at trying to come up with something sensible, 
then by all means they can try... but be warned... it's a political s***show 
for something that has such clear use case on mobile.
 
> > 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...

I'm all ears... I'm sure Ilya would be super open to that too on the Chrome 
side.  
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[mcaceres]

On Tuesday, December 20, 2016 at 3:48:10 AM UTC+11, Ehsan Akhgari wrote:
> The only potential for user control through this API is if a noticeable
> portion of websites used this API to decide whether to give the users a
> "low-res" version, and for the browser to provide some kind of a UI to
> allow the user to override the information the browser receives from the
> OS about your network connection.

Agree... and that's the footgun of the API.
 
> As things stand now, neither of the above are true to the best of my
> knowledge.

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

Re: Intent to ship: NetworkInformation

[mcaceres]

On Friday, December 16, 2016 at 8:33:48 AM UTC+11, Tantek Çelik wrote:
> On Thu, Dec 15, 2016 at 11:51 AM, Boris Zbarsky <> wrote:
> > On 12/15/16 12:20 PM, Ben Kelly wrote:
> >>
> >> Its more information than nothing.
> >
> >
> > I'm not sure it is.  At least when you have nothing you _know_ you have
> > nothing, so might think about other ways to find out what you want to know.
> > This way you think you know something but you don't.
> 
> Agreed with Boris. "more information than nothing" is not an absolute
> value, when that information is deceiving, which as others have
> pointed out in this thread, is quite likely to occur with non-trivial
> frequency in common uses of this API (the "if bandwidth>x then slow
> download" example proves this point).
> 
> E.g. a high % of the time, (most of the time when I'm not at home or
> work), I am on a 4G (high bandwidth) mifi (metered cost).
> 
> This API would report misleading results for me 100% of the time I am
> on my mifi, and for anyone else on a 4G mifi.

But you know you are on a mifi as a user: you bought the mifi, you paid for the 
mifi's contract, you connected to the mifi. Same with hotel wifi, etc. which 
may be metered. 

The point of the API is to allow the end-user and the application to negotiate 
when it's best to perform a download (not to make decisions about what is best 
and what is going to cost money). There is nothing preventing an app from 
asking the user what network type would be best to perform synchronization 
over. 

The general assumption that WIFI is cheap and 3G/4G may be sometimes wrong, but 
it holds for most users. 

> Real experience, all (AFAIK) the "sync to cloud automatically" code
> out there makes this mistake, e.g. iCloud, DropBox etc., so I've had
> to turn all of it off or just not use it.

Sure, but that goes back to Ehsan's point about perfect information: we can't 
currently get that until we get better WIFI standards or whatever. Until then, 
your mifi will look like WIFI - but that's not the APIs fault.  

Again, see the use cases document. 
 
> Let's learn from the error of "native" implementations/uses of this
> kind of API / use thereof and not repeat that mistake on web,
> certainly not ship an API that misleads web developers into doing the
> wrong thing.

The use cases document shows that native apps get this right a lot of the time. 

We are weighting the iCloud/DropBox problem against all the app examples given 
in the document. Right now, sites use a bunch of hacks to figure out if you are 
on a metered connection or not (see BBC example in the document). 

> >> Bluetooth networking is also a thing.
> >
> >
> > That's a good point.
> >
> >> I think being able to distinguish this stuff provides some value even if
> >> its not perfect for all cases.  And I don't see how it causes any harm.
> >
> >
> > I think it causes harm to give people information they have no business
> > having ("wifi" vs "ethernet") and it does harm to given them information
> > that's likely to be bogus (the last hop speed in the wifi/ethernet cases).
> 
> Precisely. Obvious harms:
> 
> 1. Privacy compromise without obvious user benefit
> 2. Causes web apps to waste user bandwidth/financial resources
> 
> If the response to that is "but doing it right is too hard", then
> don't do it all.
> 
> > Maybe the answer is that we should just reconsider the set of types that
> > gets exposed and how they get mapped to connection speeds
> 
> I'm not sure that would sufficiently address harm 2.
> 
> As far as I can tell, the only useful bit of information (as bz
> pointed out) is the
> 
> Am I on a cell data connection "for sure or maybe not"?
> a) Where cell data "for sure" -> will *almost certainly cost the user*
> b) Whereas "or maybe not" -> you have no idea whether it will cost the
> user or not, do not make any assumptions.
> 
> Given that the one pseudo-code example provided earlier in this thread
> makes the mistake of using case (b) to errantly initiate bandwidth/$
> wasting downloads (which may not even be necessary), I think this API
> has not been well thought through in terms of actual user benefit, and
> needs further incubation.

Yeah, that's why it's currently in the WICG. 

> Not to mention we shouldn't even be getting to an "Intent to *ship*"
> on something we expect to standardize that hasn't even been published
> as a FPWD yet (which only *starts* the count-down clock to IPR
> commitment).

It was originally part of DAP, so it's actually gone through years of 
publication (first published in mid 2011):
https://www.w3.org/TR/2011/WD-netinfo-api-20110607/

All the arguments presented here also got raised by the WG, which made it go 
nowhere... so we took it to the WICG for further incubation - because Google 
shipped it, and thus we were hoping for buy in from some other browser vendor.  

> Implementing behind a flag should be good enough for prototyping
> purposes to advocate for moving this from WICG to WPWG, and if 

Re: Expanding regular regression triage to include crashes?

[Astley Chen]

Agreed with that.
We should expand the search including crash keyword so that we can triage those 
issues no matter it’s a regression or high-volume crash.

—--
Best Regards,
Astley Chen | Mozilla Taiwan


On 20 Dec 2016, at 2:00 PM, Kan-Ru Chen  wrote:

On Thu, Dec 15, 2016, at 11:17 AM, Ryan VanderMeulen wrote:
> I like the idea in principle, but in practice, two meetings a week is 
> already not enough to get through regression bugs. Are we going to add 
> more meetings to accommodate this? And I'll note that already, 
> attendance of the regular regression triage meetings has declined from 
> where it was a month or two ago.

I think the most important is to identify whether the crash bugs are
regressions so they can be tracked accordingly. We have a third triage
meeting in Asia friendly timezone; I think we can try to go over the
list of crash bugs and put correct flags in the meeting.

Kanru

> Also, I thought one of the roles of the Uptime team was to triage crash 
> bugs. Is that not actually the case?
> 
> -Ryan
> 
> On 12/14/2016 9:42 PM, Jet Villegas wrote:
>> +1 on expanding the search. That should help get earlier diagnosis. We
>> should also add 'regression' to those bugs as part of triage, as
>> appropriate.
>> 
>> --Jet
> 
> ___
> 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 

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

Re: Expanding regular regression triage to include crashes?

[Kan-Ru Chen]

On Thu, Dec 15, 2016, at 11:17 AM, Ryan VanderMeulen wrote:
> I like the idea in principle, but in practice, two meetings a week is 
> already not enough to get through regression bugs. Are we going to add 
> more meetings to accommodate this? And I'll note that already, 
> attendance of the regular regression triage meetings has declined from 
> where it was a month or two ago.

I think the most important is to identify whether the crash bugs are
regressions so they can be tracked accordingly. We have a third triage
meeting in Asia friendly timezone; I think we can try to go over the
list of crash bugs and put correct flags in the meeting.

Kanru

> Also, I thought one of the roles of the Uptime team was to triage crash 
> bugs. Is that not actually the case?
> 
> -Ryan
> 
> On 12/14/2016 9:42 PM, Jet Villegas wrote:
> > +1 on expanding the search. That should help get earlier diagnosis. We
> > should also add 'regression' to those bugs as part of triage, as
> > appropriate.
> >
> > --Jet
> 
> ___
> 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: Who loves multiple selection feature in editor?

[Masayuki Nakano]

On 2016/12/17 2:32, Ehsan Akhgari wrote:

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...


My original idea was, to stop supporting multiple selection in editor 
completely. I.e., users cannot add selection range by mouse operation 
nor authors cannot add range like other browsers.


However, indeed, if user edits table, multiple selection might be 
useful. Hmm...



* 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'm talking about only nsISelectionController::SELECTION_NORMAL. Other 
selections need multiple selection.


The reason why our editor code becomes complicated is, multiple normal 
selection ranges become "edit targets". For example, when you type a 
character when there are multiple selection ranges, current editor 
removes all ranges first. Then, inserts the character at first or last 
range (I forgot which range is focused range).


At this time, we need to create loop for deleting all selection ranges, 
but the ranges may be changed/removed during handling other selection 
ranges. We don't have any spec how do we behave in such case.



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


I agree.

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

Re: Intent to ship: NetworkInformation

[Edmund Wong]

Eric Rescorla wrote:
> 
> I'm also concerned that this spec does not seem to take into account
> multipath or multihoming, both of which seem relevant here. Say that I have
> a device with both a cellular and WiFi link and I attempt to use both of
> them in some fashion (depending on the remote IP address), what should I be
> reporting for Network Connection?

Why does it matter to Firefox what network connection I use?  I would
understand Firefox needing telemetry on system specs and how it runs
against this spec, but network information?  Really?

I mean... what's wrong with:

Firefox: Can I connect to the Internet?

   Yes: Great. Proceed to connect.
   No:  Cannot connect.  Display message. Wait for user to fix issue.

Why does Firefox (or anyone other than me) CARE I have 1, 2, or a
billion network interfaces or what type they are?  Its job is to browse
the Internet.  THAT'S IT.  If Chrome wants to add it, that's their
business.

So, in conclusion, Firefox or, in fact, ANY browser, has NO business
knowing how many connections I have and what types they are.  Mobile
browsers should act just like desktop browser.  Can it connect to
the website?  Yes or No.














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

Re: Who loves multiple selection feature in editor?

[Masayuki Nakano]

On 2016/12/20 8:00, Mats Palmgren wrote:

On 12/15/2016 10:46 AM, Masayuki Nakano wrote:
 > Supporting multiple selection in editor makes our editor code
 > complicated.

Why is that so exactly?  By necessity, the code already operates
on one Range, right?  so why can't we implement something like:
Selection.ApplyToAllRanges(aFunction) that applies the existing
code to all the ranges?


That's a good point. Even if we won't remove multiple selection feature 
from editor, we should rewrite *all* selection loop with such utility.


> And for functions that doesn't make sense

to apply to all ranges, it's usually the first or last range
you want, so let's make convenience functions for those too.


Makes sense!


Would that help solve the problem?


I can say "yes" from the point of maintenance cost. But there is another 
concern. Other browsers *ignore* Selection.addRange() when there is 
already one range in the Selection. So, following code may be 
incompatible with other browsers:


onSomething() {
  let newRange = document.createRange();
  newRange.setStart(foo, bar);

  // If rangeCount is 0, the result on Gecko is same as other browsers,
  // but not so if selection already has a range.
  document.getSelection().addRange(newRange);

  // Unexpected range (newRange) will be removed on Gecko, but the
  // range may be a bug of web apps, but it won't be found with
  // testing other browsers.
  document.execCommand("delete");
}

--
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?

[Masayuki Nakano]

On 2016/12/20 6:21, Jared Wein wrote:

We currently use multiple selections for highlighting the domain in the
location bar, as well as find-in-page "highlight all". What would you
recommend we do if this is removed? I don't see how we would implement
"highlight all" without it.


I'm suggesting this issue only for normal selection (i.e., 
nsISelectionController::getSelection(nsISelectionController::SELECTION_NORMAL)). 
Multiple selection for other selection types are necessary, e.g., 
SELECTION_SPELLCHECK, SELECTION_IME_RAWINPUT, 
SELECTION_IME_SELECTEDRAWTEXT, SELECTION_IME_CONVERTEDTEXT, 
SELECTION_IME_SELECTEDCONVERTEDTEXT and SELECTION_FIND. So, perhaps, you 
don't need to mind about such feature.


(Although, I don't know which selection type is used in location bar.)

--
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?

[Mats Palmgren]

On 12/16/2016 06:32 PM, Ehsan Akhgari wrote:

* 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


Quoting Ryosuke Niwa, the current spec author:
"As a vendor (Apple), we have quite a bit of interest in improving
selection for bidirectional text and new CSS layout modes such as flex
box and grid layout which can change the order of context. One way to
achieve that would be supporting multi-range selection.
As a spec author, there has been some discussion about bringing back 
multi-range selection, there is no wide support nor consensus about it."

https://bugzilla.mozilla.org/show_bug.cgi?id=1323681#c5

Quoting Tab Atkins Jr. from the same bug:
"Yeah, Selection is just *silly* in common Grid cases under the old
'single start and end DOM locations' model. Need multi-range selection to
make it work."
https://bugzilla.mozilla.org/show_bug.cgi?id=1323681#c7

I've made an example Grid to illustrate that last point, try selecting
the first column then the second (first some A's then some B's)
(you need Nightly or DevEdition for the example to work):
https://people-mozilla.org/~mpalmgren/tests/grid/grid-selection.html
I agree with Tab that this is going to happen *a lot*.

I think we should work with Ryosuke to develop a better Selection API
so that handling multi-range Selection comes naturally.  That part
doesn't seem that hard to me; the problem is mostly about getting web
developers to use the new API, but if we can make it just a little bit
nicer than getRangeAt() then I believe we can win them over.



* 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)


* user selection over CSS '-moz-user-select:none' regions
* user selection in CSS Grid layout (eventually :-) )


/Mats

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

Re: Who loves multiple selection feature in editor?

[Mats Palmgren]

On 12/15/2016 10:46 AM, Masayuki Nakano wrote:
> Supporting multiple selection in editor makes our editor code
> complicated.

Why is that so exactly?  By necessity, the code already operates
on one Range, right?  so why can't we implement something like:
Selection.ApplyToAllRanges(aFunction) that applies the existing
code to all the ranges?  And for functions that doesn't make sense
to apply to all ranges, it's usually the first or last range
you want, so let's make convenience functions for those too.

Would that help solve the problem?

/Mats

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

Re: Intent to ship: NetworkInformation

[Martin Thomson]

On Mon, Dec 19, 2016 at 8:23 PM, Gervase Markham  wrote:
> We already do network change detection now, ISTR; could we pop a
> doorhanger when we get a network change event, of the form of something
> like "maintain 'expensive data' status Y/N?"...?

No more doorhangers please.  I have no issue with providing UX around
this, but we need to be careful about how often we bother users.
Especially with things that we should be handling for them.
___
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?

[Michael Shal]

On Fri, Dec 16, 2016 at 12:22 PM, Benoit Girard  wrote:

> 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.
>
>
A while back I wrote a series of blog posts on clobber builds that details
some of the reasons for them, and how they can be solved:

http://gittup.org/blog/2014/03/6-clobber-builds-part-1---missing-dependencies/
http://gittup.org/blog/2014/05/7-clobber-builds-part-2---fixing-missing-dependencies/
http://gittup.org/blog/2014/06/8-clobber-builds-part-3---other-clobber-causes/
http://gittup.org/blog/2015/03/13-clobber-builds-part-4---fixing-other-clobber-causes/

Though I did not go through bug 941904 / `hg log CLOBBER` to categorize the
number of times we run into various instances of missing dependencies vs.
other reasons for clobbers. That might be interesting too :)

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

Re: Who loves multiple selection feature in editor?

[Jared Wein]

We currently use multiple selections for highlighting the domain in the
location bar, as well as find-in-page "highlight all". What would you
recommend we do if this is removed? I don't see how we would implement
"highlight all" without it.

Thanks,
Jared

On Mon, Dec 19, 2016 at 3:52 PM, Johnny Stenback  wrote:

> Unless we get clear buy-in from other browsers to support this I would vote
> for removing this complexity out of Gecko.
>
>
> - jst
>
> On Mon, Dec 19, 2016 at 10:36 AM, Frederik Braun 
> wrote:
>
> > On 19.12.2016 17:19, glazou wrote:
> > > Le jeudi 15 décembre 2016 10:47:28 UTC+1, masayuki nakano a écrit :
> > >
> > >> So, it might be better to stop supporting multiple selection only in
> > >> editor if the feature is not so loved by users.
> > >
> > > We were already discussing this issue at Netscape 15 years ago but
> could
> > not come up with a good solution at that time. Thanks for bringing it
> back,
> > this could be the right time to finally solve it.
> > >
> > > Some existing use cases:
> > >
> > > 1. this is absolutely needed for table cell selection. Everyone
> > extensively using tables uses multiple selection at some point.
> > >
> >
> > I'm generally all for removing complexity and I hate to be a spoilsport.
> >  But table cell selection is pretty useful (e.g., a full row, a full
> > column and the possibility of removing a few here and there)
> >
> >
> > > 2. Microsoft Word on all platforms and in general all commercial
> > Whysiwyg Text editors allow multiple selection.
> > >
> > > 3. multiple selection is really cool if you think of images
> representing
> > videoframes you select to edit/crop a video.
> > >
> > > 4. "search a text" often ends with a multiple selection of all
> > occurrences of the pattern in the document
> > >
> > > On another hand, I think selection would benefit from a boolean
> > attribute saying if the rendering engine allows or not multiple selection
> > and if it does not, having shortcut mechanisms allowing to get rid of the
> > onmipresent and painful getRangeAt(0). We do quite equivalent things when
> > the selection is collapsed.
> > >
> > > 
> > > ___
> > > 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
> >
> ___
> 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: Who loves multiple selection feature in editor?

[Johnny Stenback]

Unless we get clear buy-in from other browsers to support this I would vote
for removing this complexity out of Gecko.


- jst

On Mon, Dec 19, 2016 at 10:36 AM, Frederik Braun  wrote:

> On 19.12.2016 17:19, glazou wrote:
> > Le jeudi 15 décembre 2016 10:47:28 UTC+1, masayuki nakano a écrit :
> >
> >> So, it might be better to stop supporting multiple selection only in
> >> editor if the feature is not so loved by users.
> >
> > We were already discussing this issue at Netscape 15 years ago but could
> not come up with a good solution at that time. Thanks for bringing it back,
> this could be the right time to finally solve it.
> >
> > Some existing use cases:
> >
> > 1. this is absolutely needed for table cell selection. Everyone
> extensively using tables uses multiple selection at some point.
> >
>
> I'm generally all for removing complexity and I hate to be a spoilsport.
>  But table cell selection is pretty useful (e.g., a full row, a full
> column and the possibility of removing a few here and there)
>
>
> > 2. Microsoft Word on all platforms and in general all commercial
> Whysiwyg Text editors allow multiple selection.
> >
> > 3. multiple selection is really cool if you think of images representing
> videoframes you select to edit/crop a video.
> >
> > 4. "search a text" often ends with a multiple selection of all
> occurrences of the pattern in the document
> >
> > On another hand, I think selection would benefit from a boolean
> attribute saying if the rendering engine allows or not multiple selection
> and if it does not, having shortcut mechanisms allowing to get rid of the
> onmipresent and painful getRangeAt(0). We do quite equivalent things when
> the selection is collapsed.
> >
> > 
> > ___
> > 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Async scrollbar dragging enabled on Nightly

[Botond Ballo]

Async scrolling (APZ) has been enabled for a new input method,
scrollbar dragging, on the Nightly branch.

This was initially implemented by Benoit Girard about a year ago,
briefly enabled on Nightly, and then disabled again due to regressions
that we didn't have the time to fix at the time. It languished on the
back burner until it was picked up recently by Kevin Wern, a volunteer
contributor who has been doing some great work for APZ. Thanks, Kevin,
for getting this in good enough shape to enable on Nightly again!

There are three known issues with this feature.

Two of them are hard to reproduce:
Bug 1249750 - Content area occasionally goes blank when dragging
scrollbar with APZ drag enabled
Bug 1250649 - async drag: Dragging while the scrollbar's max value
changes permanently breaks scrolling
If you encounter these, please post testcases / URLs to these bugs.

The third one, bug 1251617, is that a quick drag on a long page
results in checkerboarding. This is hard to fix, and can be thought of
as a conscious tradeoff: we're deliberately allowing you to drag
faster than we can paint the content you're moving over. If you have
any thoughts about this tradeoff, please post them to this bug.

If you encounter any other regressions related to scrollbar dragging,
please file bugs blocking bug 1211610, which is the tracking bug for
this work.

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

Re: Who loves multiple selection feature in editor?

[Frederik Braun]

On 19.12.2016 17:19, glazou wrote:
> Le jeudi 15 décembre 2016 10:47:28 UTC+1, masayuki nakano a écrit :
> 
>> So, it might be better to stop supporting multiple selection only in 
>> editor if the feature is not so loved by users.
> 
> We were already discussing this issue at Netscape 15 years ago but could not 
> come up with a good solution at that time. Thanks for bringing it back, this 
> could be the right time to finally solve it.
> 
> Some existing use cases:
> 
> 1. this is absolutely needed for table cell selection. Everyone extensively 
> using tables uses multiple selection at some point.
> 

I'm generally all for removing complexity and I hate to be a spoilsport.
 But table cell selection is pretty useful (e.g., a full row, a full
column and the possibility of removing a few here and there)


> 2. Microsoft Word on all platforms and in general all commercial Whysiwyg 
> Text editors allow multiple selection.
> 
> 3. multiple selection is really cool if you think of images representing 
> videoframes you select to edit/crop a video.
> 
> 4. "search a text" often ends with a multiple selection of all occurrences of 
> the pattern in the document
> 
> On another hand, I think selection would benefit from a boolean attribute 
> saying if the rendering engine allows or not multiple selection and if it 
> does not, having shortcut mechanisms allowing to get rid of the onmipresent 
> and painful getRangeAt(0). We do quite equivalent things when the selection 
> is collapsed.
> 
> 
> ___
> 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: Who loves multiple selection feature in editor?

[Ehsan Akhgari]

On 2016-12-18 5:09 PM, Karl Dubost wrote:
> As Ehsan said:
> 
> Le 17 déc. 2016 à 02:32, Ehsan Akhgari  a écrit :
>> (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.)
> 
> I know it for a very long time and it's very practical to me when I want for 
> example to reply to a specific part of a text but don't want to copy, paste 
> and trim. 
> 
> It is one of these very useful features where Firefox is leading, but that we 
> do not advertise this as user benefits. Missed opportunity. Instead of 
> removing it I would probably vote for making it known ;)

Note that this feature in editable regions is significantly broken.
While I sympathize with your feeling about the usefulness of this
feature outside of editable regions, I wouldn't want to expose it more
broadly before addressing the issues that this thread is discussing.

___
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-18 4:16 PM, Karl Dubost wrote:
> When reading a thread about a new API or feature such as…
> 
> Le 16 déc. 2016 à 04:39, Ehsan Akhgari  a écrit :
>>  From what I remember, the argument for shipping
>> this API was that web developers have been asking for this for years,
>> and they are basically happy to know the distinction between cellular
>> data and other transports, and infer whether the connection "costs
>> money". 
> 
> 
> I have always in the back of my mind:
> 
> * How does it give control (benefits) to
>   - users? 
>   - web developers?
>   - UX/Designers?
>   - marketers/analytics crunchers/BD?
> 
> Maybe there is a bit more user research (or maybe Marcos knows this already) 
> to do in what users want to do? I guess we all have our own ideas about it. 
> 
> Mine would be more give me a possibility to choose in the chrome what type of 
> assets/performances I desire. I am on high performance bandwidth/latency 
> network, but I want low-res, because I just want speed (the same way I would 
> access a mobile domain m. for quick access on desktop). Or give me the 
> high-res pictures on my slow network because I really need this high quality 
> images I want to share with someone else and/or print.

The only potential for user control through this API is if a noticeable
portion of websites used this API to decide whether to give the users a
"low-res" version, and for the browser to provide some kind of a UI to
allow the user to override the information the browser receives from the
OS about your network connection.

As things stand now, neither of the above are true to the best of my
knowledge.

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

Re: Who loves multiple selection feature in editor?

[glazou]

Le jeudi 15 décembre 2016 10:47:28 UTC+1, masayuki nakano a écrit :

> So, it might be better to stop supporting multiple selection only in 
> editor if the feature is not so loved by users.

We were already discussing this issue at Netscape 15 years ago but could not 
come up with a good solution at that time. Thanks for bringing it back, this 
could be the right time to finally solve it.

Some existing use cases:

1. this is absolutely needed for table cell selection. Everyone extensively 
using tables uses multiple selection at some point.

2. Microsoft Word on all platforms and in general all commercial Whysiwyg Text 
editors allow multiple selection.

3. multiple selection is really cool if you think of images representing 
videoframes you select to edit/crop a video.

4. "search a text" often ends with a multiple selection of all occurrences of 
the pattern in the document

On another hand, I think selection would benefit from a boolean attribute 
saying if the rendering engine allows or not multiple selection and if it does 
not, having shortcut mechanisms allowing to get rid of the onmipresent and 
painful getRangeAt(0). We do quite equivalent things when the selection is 
collapsed.


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

[Firefox Desktop] Issues found: December 12th to December 16th

[Florin Mezei]

Hi everyone,


Here's the list of new issues found and filed by the Desktop Release QA Team 
last week, December 12 - December 16 (week 50).

Additional details on the team's priorities last week, as well as the plans for 
the current week are available at:

https://public.etherpad-mozilla.org/p/DesktopManualQAWeeklyStatus


RELEASE CHANNEL
none

BETA CHANNEL

none

AURORA CHANNEL


ID

Summary

Product

Component

Is a regression

Assigned to

Status


1322349  

Cannot exit Fullscreen mode with touch enabled

Core

Panning and Zooming

 

 YES

Kartikaya Gupta  

NEW


NIGHTLY CHANNEL

none

ESR CHANNEL


ID

Summary

Product

Component

Is a regression

Assigned to

Status


1323006  

60% PDF zoom level between Page Width and 50% displayed while navigating with 
keyboard

Firefox

PDF Viewer

YES

NOBODY

NEW

 

Regards, 

Florin.

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

Re: Intent to ship: NetworkInformation

[Daniel Stenberg]

On Mon, 19 Dec 2016, Gervase Markham wrote:

We already do network change detection now, ISTR; could we pop a doorhanger 
when we get a network change event, of the form of something like "maintain 
'expensive data' status Y/N?"...?


Nice idea!

However the network changes we detect currently are a bit too frequent and not 
precise enough to be good enough for something like that. (Like we also 
trigger them for example when we come back from sleep plus the fact that 
occasional false positives don't hurt a lot when there's nothing visible 
showing them.)


Once we get network detection done[*] in a satisfying manner it would be cool 
to have such a bit remembered on a per-network basis so that we could have 
Firefox remember the status when tethered and then switch back automatically 
when going back to regular wire/ethernet etc!


[*] = I have basic work of this landed but the error rate is still too high to 
build on it but there are more things to do to improve the situation. The idea 
is to find network details that help us identify which network we're on and 
then subsequently detect when we come back to a network we've been on before. 
Details such as MAC address of the default gateway or the global IPv6 prefix.


--

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

Re: Intent to ship: NetworkInformation

[Gervase Markham]

On 16/12/16 20:25, Jason Duell wrote:
> 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.

We already do network change detection now, ISTR; could we pop a
doorhanger when we get a network change event, of the form of something
like "maintain 'expensive data' status Y/N?"...?

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