Re: Changes to tab min-width

[Ehsan Akhgari]

On 10/04/2017 12:43 PM, Jeff Griffiths wrote:
Om my system ( retina macbook pro ) 70 is starting to look like a 
better compromise for tab readability.
I think 70 is better than 50, but I noticed that if a foreground tab 
starts to play audio and we need to show the audio icon alongside the 
tab close icon, the 70px width is actually not enough and the tab pushes 
its width out a bit!  I think we need to consider a minimum of 75px instead.


But still I think this is a serious degradation for existing users who 
have many tabs in terms of the readability of the titles, but we can 
mitigate it by perhaps reducing the padding.  For example, see this 
screenshot:


https://ehsanakhgari.org/wp-content/uploads/2017/10/tabminwidth-narrowpaddings.png

It shows at above browser.tabs.tabMinWidth = 100 and below 
browser.tabs.tabMinWidth = 75 with the paddings in each tab reduced by 
13 pixels.  There is very little reduction to the amount of space 
available for the tab title if we do something like this, I think...


Cheers,
Ehsan



How I have been testing this:

  * change the value to a specific number, say 70
  * open enough tabs so that overflow triggers, then close two tabs,
then open a tab ( we retain overflow until 2 tabs have been closed! )
  * count the number of tabs opened
  * open chrome and open that number of tabs
  * compare the utility of each browser

Jeff

On Wed, Oct 4, 2017 at 9:37 AM, Marco Bonardo > wrote:


On Tue, Oct 3, 2017 at 10:36 PM, Jeff Griffiths
> wrote:
> 1. do you prefer the existing behaviour or the new behaviour?
> 2. if you prefer a value for this pref different than 50 or 100,
what
> is it? Why?

I prefer being able to see a minimum part of the title, because I very
often have multiple tabs open on the same page (many bugzilla, many
searchfox, many crash-stats) and now I cannot distinguish them at all.
But at the same time, I never liked much the scrolling behavior, at a
point that when my tabs start scrolling, I begin a cleaning taks to
close some of them.
Looks like I'm unhappy in both cases, sorry. If I'd really have to
pick, I'd probably would like to see the first 10 chars of the title.




___
firefox-dev mailing list
firefox-...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev


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

Re: Changes to tab min-width

[Gian-Carlo Pascutto]

On 4/10/2017 18:15, Jeff Griffiths wrote:
> The feedback I am going to find actionable here is, which
> setting value of this preference do you find most useful.

Jeff,

I've read through all the responses here, and I've seen several people
point out the same problem I did: we're getting the worst of both worlds
right now.

You neither get the fixed positioning of infinite tabs (<50px), and you
don't get the readable titles of scrolling tabs (70-100px).

Is it technically difficult to try the technique of starting with 50px,
and switching to 100px as soon as 50px wouldn't fit anyway? Maybe that
ends up not working well in practice, but what we got now isn't going to
make anyone happy either. So it seems worth trying?

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

Re: Changes to tab min-width

[Gian-Carlo Pascutto]

On 5/10/2017 19:35, Boris Zbarsky wrote:
> On 10/5/17 1:05 PM, Gian-Carlo Pascutto wrote:
>> [1] I'm sure users that have been conditioned that there exists only a
>> single search engine are going to be confused by the choice that it
>> offers. Maybe we should remove the search box and switch to an Omnibar.
> 
> Um... haven't we?  Current nightlies have only one bar by default.

It was sarcasm - condemned to a footnote so my ranting wouldn't
interfere with the more important main points.

The search box and the ability to use large number of tabs are things I
consider strong competitive advantages of Firefox over Chrome. I'm not
sure what to think about us getting rid of them. (Contrast to throwing
the add-on ecosystem on the fire: there were strong upsides to that and
the advantage had gotten very debatable. I don't think that applies here
though)

My nightmare right now would be that people get so used to Electron
apps' misrendered fonts on Windows that they ask us to copy the
behavior, because they get conditioned that text is supposed to be hard
to read.

Anyway, enough ranting, there's work to do.

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

Re: Changes to tab min-width

[Gian-Carlo Pascutto]

On 03-10-17 22:36, Jeff Griffiths wrote:
> We did this based on some early feedback from a few different sources
> that people coming from chrome 

That's rather ironic. I have always thought that one reason why Chrome
uses these uselessly-tiny tabs is to *discourage* users from hoarding a
lot of tabs and thus ballooning the memory usage with one-tab-per-process.

This can be effectively done by making the browser unusable as soon as
you have a lot of tabs, hence, by making them unreadably small and
impossible to click in that case. And now we're copying this behavior
because Chrome users are conditioned to it.

Madness. [1]

> comments: chrome's "infinite tabs visible" approach results in a much
> higher usable/visible tab count in a given window than ours does. 

Visible, yes. Usable, I don't think so!

> I want feedback on this change from these lists, and will also be
> looking for feedback from the original sources of this complaint. In
> particular:
> 
> 1. do you prefer the existing behaviour or the new behaviour?

The existing behavior, by miles.

The problem of the new behavior is that I now have a tab strip with long
streaks of identical icons. How am I going to find anything in here?
Click all of them (now much harder, because the click target is half the
size!), wait for the page to load, move on to the next one? The
usability degradation of this is insane. In fact, it makes it pointless
to keep tabs open, as I have to find them via the awesomebar now and I
might as well just re-open the webpages then, the workflow is the same.

Thinking about what could possibly trigger someone to want this
behavior, I'm guessing there's an intermediate zone where you have a few
tabs open, enough that we would start scrolling them off-screen, but
little enough that they still fit in one window with smaller titles. In
that case, hunting for the right tab probably is easier if you don't
have to scroll, especially as the position will stay fixed(!) and the
amount of times you will guess wrong is smaller.

This also implies that changing the min-width to be smaller *and*
keeping the scrolling will get you the worst of both worlds in terms of
usability. If anything, if the amount of tabs increases to the point
where scrolling is required, I see no reason whatsoever not to restore a
sensible min-width at that exact moment.

> 2. if you prefer a value for this pref different than 50 or 100, what
> is it? Why?

Whatever the previous default was is good enough and infinitely better
than what we have now.

[1] I'm sure users that have been conditioned that there exists only a
single search engine are going to be confused by the choice that it
offers. Maybe we should remove the search box and switch to an Omnibar.

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

Intent to implement and ship PerformanceResourceTiming.workerStart

[Ben Kelly]

The PerformanceResourceTiming API has had a `workerStart` value specified
for a couple years now.  Its defined to represent the time when we trigger
a service worker FetchEvent.  It will be zero if service workers are not
involved.

https://bugzilla.mozilla.org/show_bug.cgi?id=1191943
https://w3c.github.io/resource-timing/#dom-performanceresourcetiming-workerstart

This will be available on all platforms.

I'm targeting it for release in FF58.

It is not behind a pref.  The property will always be there.  If SW are
disabled then the value will always be zero.

We have some work going on to try to display service worker timing
information in devtools:

https://bugzilla.mozilla.org/show_bug.cgi?id=1353798

Chrome has implemented workerStart for a while and there is a WPT test.

There are some spec/compat questions to clarify:

https://github.com/w3c/resource-timing/issues/118
https://github.com/w3c/resource-timing/issues/119

But I don't think those need to block shipping the property.  We can adjust
the values as the spec is clarified.  Also, one of the reasons I am
implementing this now is so we can enable the WPT test.  Our
PerformanceResourceTiming code is completely broken for SW in e10s right
now and we missed it because the test is not passing.  (This will be fixed
in FF58 as well.)

The WPT test is here and is being expanded slightly with our implementation:

https://searchfox.org/mozilla-central/source/testing/web-platform/tests/service-workers/service-worker/resource-timing.https.html

Please let me know if there are questions or concerns.  Thanks.

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

Re: Intent to ship: Throttling timeouts in background using execution budget.

[Gabor Krizsanits]

Thanks a lot for working on this, it sounds awesome! Can I ask if there are
any related telemetry probes that will be used later on to evaluate the
results and maybe tune these constants? Do you plan to expose any of these
parameters to web extensions?

Gabor

On Thu, Oct 5, 2017 at 5:27 PM, Andreas Farre  wrote:

> Hi all!
>
> After Bug 1377766 lands, we will increase the amount timeouts
> executing in background tabs are throttled, based on an execution
> budget. This budget is continuously regenerating, and is decreased
> when timeouts execute. If the budget becomes negative, timeouts will
> not be allowed to run until the budget is positive again. This
> punishes pages that behave poorly while not being in the foreground.
>
> This feature has been developed behind
> "dom.timeout.enable_budget_timer_throttling". Other relevant prefs
> are:
>
> * dom.timeout.background_budget_regeneration_rate
>   The rate of budget regeneration; the time in milliseconds that it
> takes to regenerate 1 millisecond
>
> * dom.timeout.background_throttling_max_budget
>   The maximum budget. Budget is clamped to this.
>
> * dom.timeout.budget_throttling_max_delay
>   Effectively the minimum budget. The maximum delay of a throttled timeout
>
> * dom.timeout.foreground_budget_regeneration_rate
>   The same as the background variant, but for foreground tabs. Only
> applicable for testing.
>
> * dom.timeout.foreground_throttling_max_budget
>   The same as the background variant, but for foreground tabs. Only
> applicable for testing.
>
> * dom.timeout.throttling_delay
>   The amount of time we require to pass after a page has completely
> loaded until we start throttling.
>
> The default values of these prefs are:
>
> dom.timeout.background_budget_regeneration_rate: 100
>
> dom.timeout.background_throttling_max_budget: 50
>
> dom.timeout.budget_throttling_max_delay: 15000
>
> dom.timeout.foreground_budget_regeneration_rate: 1
>
> dom.timeout.foreground_throttling_max_budget: -1
>
> dom.timeout.throttling_delay: 3
>
> This is read as: budget regenerates 10 ms per second and will never
> grow beyond 50 ms. If the execution budget is negative a timeout will
> not run until it becomes positive, which happens at the said rate, but
> it will also not be delayed more than 15 seconds. Throttling for
> foreground is effectively turned off. Throttling doesn't commence
> until after 30 seconds.
>
> Google has a similar feature[1] for timer throttling.
>
> Turning on this feature is tracked in Bug 1377766 [2]
>
> It is inherently difficult to test this feature without false
> negatives due to the timing dependency of the feature. Bug 1378402
> tracks adding tests for testing throttling, but they suffer from being
> a bit too intermittent still. At least for debug builds.
>
> My hope by getting this in early in the release cycle is to be able to
> actively evaluate the feature, so I hope that you take the time to
> report those bugs! :)
>
> My hope is that this will land on Monday October 9th if there are no
> objections.
>
> Cheers, Andreas
>
> [1] https://developers.google.com/web/updates/2017/03/
> background_tabs#budget-based_background_timer_throttling
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1377766
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1378402
> ___
> 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

Intent to ship: Throttling timeouts in background using execution budget.

[Andreas Farre]

Hi all!

After Bug 1377766 lands, we will increase the amount timeouts
executing in background tabs are throttled, based on an execution
budget. This budget is continuously regenerating, and is decreased
when timeouts execute. If the budget becomes negative, timeouts will
not be allowed to run until the budget is positive again. This
punishes pages that behave poorly while not being in the foreground.

This feature has been developed behind
"dom.timeout.enable_budget_timer_throttling". Other relevant prefs
are:

* dom.timeout.background_budget_regeneration_rate
  The rate of budget regeneration; the time in milliseconds that it
takes to regenerate 1 millisecond

* dom.timeout.background_throttling_max_budget
  The maximum budget. Budget is clamped to this.

* dom.timeout.budget_throttling_max_delay
  Effectively the minimum budget. The maximum delay of a throttled timeout

* dom.timeout.foreground_budget_regeneration_rate
  The same as the background variant, but for foreground tabs. Only
applicable for testing.

* dom.timeout.foreground_throttling_max_budget
  The same as the background variant, but for foreground tabs. Only
applicable for testing.

* dom.timeout.throttling_delay
  The amount of time we require to pass after a page has completely
loaded until we start throttling.

The default values of these prefs are:

dom.timeout.background_budget_regeneration_rate: 100

dom.timeout.background_throttling_max_budget: 50

dom.timeout.budget_throttling_max_delay: 15000

dom.timeout.foreground_budget_regeneration_rate: 1

dom.timeout.foreground_throttling_max_budget: -1

dom.timeout.throttling_delay: 3

This is read as: budget regenerates 10 ms per second and will never
grow beyond 50 ms. If the execution budget is negative a timeout will
not run until it becomes positive, which happens at the said rate, but
it will also not be delayed more than 15 seconds. Throttling for
foreground is effectively turned off. Throttling doesn't commence
until after 30 seconds.

Google has a similar feature[1] for timer throttling.

Turning on this feature is tracked in Bug 1377766 [2]

It is inherently difficult to test this feature without false
negatives due to the timing dependency of the feature. Bug 1378402
tracks adding tests for testing throttling, but they suffer from being
a bit too intermittent still. At least for debug builds.

My hope by getting this in early in the release cycle is to be able to
actively evaluate the feature, so I hope that you take the time to
report those bugs! :)

My hope is that this will land on Monday October 9th if there are no objections.

Cheers, Andreas

[1] 
https://developers.google.com/web/updates/2017/03/background_tabs#budget-based_background_timer_throttling
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1377766
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1378402
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

CodeCoverage Monthly Update

[Kyle Lahnakoski]

*# Q3 Codecoverage! update *

/If you //want to hear more about an//y of the//s//e items, please
contact me and I will get you more detailed information/*
*

*## Overview *

We can show the code coverage on new lines added by changeset!

  * *Link* - http://firefox-code-coverage.herokuapp.com/
  * *Warning* - This is alpha-quality; it is a work-in-progress, there
are still bugs, and it is not as responsive as we would like
  * *Visual walk through* -

https://github.com/armenzg/firefox-code-coverage-frontend/raw/7b67f2e948de94b7f837ba9a7c57a31e810d9fe7/docs/Prototype%20Instructions.pdf

Of course, we still have the regular coverage that we upload to
codecov.io [4] https://codecov.io/gh/marco-c/gecko-dev

*## Parts you don't see*

  * *Keep the tests passing* - Code coverage builds run a little
different, so we must constantly monitor and triage the unique test
failures.
  * *Building the backend for the UI* - The UI is supported by a backend
service that maps coverage to the changesets
  * *optimize jsvm lcov rewriter* - because everything is slow at our
scale of coverage
  * *merge coverage from test chunks* - because codecov.io can not
handle our raw data volume
  * *adding function info to grcov *- a different resolution of coverage
that is consistent with other coverage tools
  * *Rust LLVM build*  - We require a special build of Rust in order to
collect Rust coverage;

https://treeherder.mozilla.org/#/jobs?repo=try=014e361716000d0dee4427bf7195316a2aba7b21

*## Future Plans*

  * *Verify this UI prototype* - We want to ensure RelMan can use this
to inform their bug risk assessment
  * **Improve the UI* - *There are inevitable changes to be made when we
get our feedback from RelMan, plus the known bugs and issues we need
to work on.
  *

  * *Coverage for Windows with Clang* -
https://bugzilla.mozilla.org/show_bug.cgi?id=1381163
  * *Solve bugs* - Of course, there is a long tail of bugs 
  * *Show what tests cover a file* - Experimental - a couple UCOSP
students will attempt to show coverage at the per-test level; this
should prove useful to those that made a code change, and would like
to know what test suite (or test chunk) covers it.  If useful, then
we can use this same information to inform our automation.
  * *Merge coverage from different revisions* - Experimental - a UCOSP
student will attempt a pan-temporal representation of our source
code: If done, it will allow us transport code coverage forward, and
backward, through time and revisions.  This can be used to compare
coverage runs, merge runs from different revisions, and allow us to
collect coverage at a higher resolution with lower data storage costs.

*## Meetings*

We have weekly CodeCoverage meetings, and you are welcome to attend:

  * *When* - Held every Friday @ 11:30 EDT (08:30 PDT)
  * *Where* - Kyle's video room
https://v.mozilla.com/flex.html?roomdirect.html=huhL8WaTwCwC
  * *Etherpad* - https://public.etherpad-mozilla.org/p/code_coverage_Q1_17

*## Links*

[1] The frontend UI http://firefox-code-coverage.herokuapp.com/

[2] Frontend code https://github.com/armenzg/code_cov_experiments

[3] Backend server
https://github.com/mozilla-releng/services/tree/master/src/shipit_uplift/shipit_uplift

[4] Total Coverage https://codecov.io/gh/marco-c/gecko-dev

[5] UCOSP - http://ucosp.ca/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[Chris Hutten-Czapski]

I prefer the old behaviour, but I don't have a strong opinion on the
matter. I think it's because I'm used to tab navigation by keyboard
shortcut more than by mouse. I rearrange tabs so that they're close
together.

For everyone curious about how much of an outlier your subsessions are...
on Nightly 58: https://mzl.la/2ge6Bpk
Over 20% of subsessions have only one tab.
50% of subsessions have 3 or fewer
Over 90% of subsessions have 20 or fewer.
99% of subsessions have 218 or fewer tabs open concurrently.

Of course this is wildly different on other[1] channels: (
Beta 57's 99%ile is at 22[1]
Release 56's 99%ile is at 148, with 94% of subsessions with 20 or fewer
tabs[2]

Note: telemetry.mozilla.org is per-subsession aggregation, not per-client,
so clients with more subsessions are weighted more heavily
(pseudoreplication). Just something to keep in mind.

:chutten

[1]: https://mzl.la/2gdB1YP
[2]: https://mzl.la/2gdXftM


On Wed, Oct 4, 2017 at 4:46 PM, Girish Sharma 
wrote:

> +1 to 75px.
> All the points that I wanted to say about 50px being too small have
> already been said by now.
>
> On Thu, Oct 5, 2017 at 1:29 AM, Dirkjan Ochtman 
> wrote:
>
>> On Tue, Oct 3, 2017 at 10:36 PM, Jeff Griffiths 
>> wrote:
>>
>>> 1. do you prefer the existing behaviour or the new behaviour?
>>> 2. if you prefer a value for this pref different than 50 or 100, what
>>> is it? Why?
>>>
>>
>> Like others, I really like ~75 pixels. This allows me to see the first
>> 5-6 characters of the page's title, which I find really helpful in
>> distinguishing tabs. At 50 pixels, it's really only the favicon, which
>> seems much less helpful in my usage.
>>
>> Cheers,
>>
>> Dirkjan
>>
>> ___
>> firefox-dev mailing list
>> firefox-...@mozilla.org
>> https://mail.mozilla.org/listinfo/firefox-dev
>>
>>
>
>
> --
> Girish Sharma
> B.Tech(H), Civil Engineering,
> Indian Institute of Technology, Kharagpur
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

[Frederik Braun]

On 02.10.2017 18:43, Anne van Kesteren wrote:
> On Mon, Oct 2, 2017 at 6:09 PM, Boris Zbarsky  wrote:
>> On 10/2/17 12:03 PM, Daniel Veditz wrote:
>>> Fair enough. Could we propose improvements to the APIs that would make
>>> them more usable? For example an object argument to createElement() that
>>> contained attribute/value pairs?
>>
>> This has definitely been proposed before.  Worth checking with Anne to see
>> what the status is.  Specifically, did it die, and if so why? Because I,
>> too, think this would be an interesting avenue to explore...
> 
> See https://github.com/whatwg/dom/issues/150. There's not really any
> dominant pattern that's succeeded here in libraries that we could
> adopt. You typically end up looking at templating and that has its own
> host of issues. The other thing that would solve some of this is
> browser-backed sanitization, but that's also a hard problem to solve
> nobody has been willing to tackle and get standardized.
> 
> 

Some folks are Google are working on a solution based on Types:


I've tried providing feedback here and there, but they are moving fast
and I'm not included in all of their conversations, since they are not
public (despite their good history of working with W3C WebAppSec). :(
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

[Frederik Braun]

On 02.10.2017 18:03, Daniel Veditz wrote:
> ​Fair enough. Could we propose improvements to the API​s that would make
> them more usable? For example an object argument to createElement() that
> contained attribute/value pairs?
> 
>   var div = document.createElement("div", null, {"id":"foo",
> "class":"bar"});
>   parent.prepend(div);
> 
> (the null is for the existing custom elements options param)

Well, you _could_ write something like

var div = Object.assign(document.createElement("div"), {
id: "foo",
className: "bar",
});
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform