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.)
> >
> > Exp
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
> all
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 h
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 Vand
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 regula
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
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
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
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 t
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 i
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
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
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 reas
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 St
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 :
> >
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 lan
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
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 thei
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 b
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
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/De
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
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
23 matches
Mail list logo
