Re: Changes to tab min-width

[Dirkjan Ochtman]

On Sat, Nov 18, 2017 at 7:38 AM,  wrote:

> 57 is unusable for me..I keep 35-50 tabs open at any given time and I used
> Custom Tab Width legacy extension to prevent scrolling. I CANNOT stand
> scrolling thru tabs. I don't need to read the tab- I KNOW where they are.
> It should be simple to allow tabminwidth to go lower than currently
> configured. Then the user could decide how THEY like it. If this doesn't
> happen soon I will be reverting to an older versio nof FF or switching
> browsers altogether. btw..there is still some memory leak with FF. After a
> day I have to restart FF or it would eat all remaining Mem on my 8G system.


Luckily, Firefox has your back. From the first message in this thread:

On Tuesday, October 3, 2017 at 3:36:40 PM UTC-5, Jeff Griffiths wrote:
> 1. it reintroduces an old preference 'browser.tabs.tabMinWidth' that
> contains a pixel value that controls the minimum width of a tab.

Which you can easily set to a different value that works better for you.

Cheers,

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

Re: Changes to tab min-width

[wade]

On Tuesday, October 3, 2017 at 3:36:40 PM UTC-5, Jeff Griffiths wrote:
> Hi!
> 
> tl;dr we changed the default pixel value at which we overflow tabs,
> and I want your feedback.
> 
> We just added a change to m-c[1] that does to things:
> 
> 1. it reintroduces an old preference 'browser.tabs.tabMinWidth' that
> contains a pixel value that controls the minimum width of a tab.
> 
> 2. it sets the default value of the tab to 50, previously this value
> was hard-coded at 100.
> 
> Work is being tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1404465
> 
> We did this based on some early feedback from a few different sources
> that people coming from chrome ( or in some cases, existing users )
> thought that the Firefox behaviour of scrolling the tabstrip was
> off-putting. We looked into this and I generally agree with the
> comments: chrome's "infinite tabs visible" approach results in a much
> higher usable/visible tab count in a given window than ours does. This
> change puts us roughly at par.
> 
> To put this in numbers:
>  * in chrome I can open ~ 24 tabs before the tabstrip's usability is
> degraded a lot
>  * in current firefox, I can open ~ 12 tabs before tabstrip scrolling kicks in
>  * with this change applied I can open 25 tabs with the pref value set to 50px
> 
> ( Caveats: this was on the built-in display on my Macbook Pro with the
> default theme, your mileage may vary, etc )
> 
> 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?
> 2. if you prefer a value for this pref different than 50 or 100, what
> is it? Why?
> 
> One aspect that I would like to stress about this change: most
> existing Firefox users will never see it, because they are unlikely to
> open m,ore than 10 tabs at any one time. So what we are really talking
> about is a change that will trade being able to see more tabs vs being
> able to read more text in each tab title.
> 
> Moving forward there are a few different options:
> 
> 1. uplifting this change into 57 ( possibly with a different default
> value ) If we think the patch has a generally positive effect and no
> downsides, we may decide to uplift into 57 Beta and let it ride the
> trains.
> 
> 2. keeping the change in 58, possibly with a different value.
> 
> 3. keeping the change in 58, preserving the current setting of 100px
> and providing an alternate pref ( probably a toggle or predefined
> values ) for "skinnier" tabs.
> 
> Longer term I intend to propose a more in-depth study of tab behaviour
> among different user segments and assess different strategies for
> heavier tab users including things like horizontal tab scaling,
> vertical tabs, etc. I can't see that happening before Q1 next year.
> 
> cheers, Jeff
> 
> [1] https://hg.mozilla.org/integration/autoland/rev/a75e0386aad8

57 is unusable for me..I keep 35-50 tabs open at any given time and I used 
Custom Tab Width legacy extension to prevent scrolling. I CANNOT stand 
scrolling thru tabs. I don't need to read the tab- I KNOW where they are. It 
should be simple to allow tabminwidth to go lower than currently configured. 
Then the user could decide how THEY like it. If this doesn't happen soon I will 
be reverting to an older versio nof FF or switching browsers altogether. 
btw..there is still some memory leak with FF. After a day I have to restart FF 
or it would eat all remaining Mem on my 8G system.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Implement and Ship: HTMLTextAreaElement.autocomplete

[Matthew N.]

*Summary*:
Allows web developers to get the effective/normalized value of the
autocomplete attribute in the same way they currently can for  and
.​

Example:  returns "on" for
textarea.autocomplete.
The return value will respect the pref dom.forms.autocomplete.formautofill,
like we already do for  and  meaning it will only return
"on"/"off" if Form Autofill isn't available to support the other values.

*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1020698
*Link to standard*:
https://html.spec.whatwg.org/#the-textarea-element:attr-fe-autocomplete
*Platform coverage*: All but iOS
*Estimated or target release*: Firefox 59
*Preference behind which this will be implemented*: None (it's simply
exposing shared logic for  and  on 
*Is this feature enabled by default in sandboxed iframes*
​:​
Yes
*DevTools bug*: N/A since it's just a
​fairly basic DOM property. In theory devtools could use the internal
getAutocompleteInfo API to show the browsers' interpretation of the parsed
attribute.
*Do other browser engines implement this*
​:​
According to https://wpt.fyi/html/dom/interfaces.html's
"HTMLTextAreaElement interface: attribute autocomplete" row:
* Safari: Shipped 
​ in unknown version 
* Chrome: N
​ot yet

​​
​ , but​
​i​
nten
​ding​
to
​i​
mplement and
​s​
hip

* Edge: No
*Tests -*
*​*
* Is this feature fully tested by web-platform-tests*
​:​
​ https://wpt.fyi/html/dom/interfaces.html has basic interface tests and ​
https://wpt.fyi/html/semantics/forms/the-form-element/form-autocomplete.html
tests the common parsing logic (not specific to )

​Thanks,
Matthew N. (:MattN)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSP Violation DOM Events

[Daniel Veditz]

On Fri, Nov 17, 2017 at 9:25 AM, James Graham 
wrote:

> On 17/11/17 16:06, Daniel Veditz wrote:
>
>> We fail many of the existing CSP web platform tests, despite having
>> implemented most of the features, because they were written to use the
>> violation events to check the results.​
>>
>> Is that an issue with our implementation or something we should fix in
> the tests? In either case it seems problematic to have such a feature and
> no way of checking for compatibility with other implementations.
>

​The issue with our implementation is that we don't yet support CSP
violation DOM events​ (this Intent to Ship) and that very feature is relied
on by most of the existing CSP web platform tests. Could you fix the tests?
I suppose you could set up a CSP reporting end point and check test results
that way, but that would add complexity just to work around the fact that
we haven't implemented this one bit of the spec, which we are now
implementing.

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

service workers at risk for FF59 ESR

[Ben Kelly]

As you may be aware, we have disabled service workers in all ESR releases
since it was implemented.  At first this was because it was a big new
feature with security implications.  Then it was because we realized we
needed to rewrite a lot of code to properly support multi-e10s.  Back
porting security fixes across such a rewrite would be quite difficult.

Unfortunately it looks probable that we will need to disable service
workers in FF59 ESR as well.

There is some small hope that we will complete the service workers e10s
rewrite in FF59.  However, its also very likely this will not get done
given that the all hands, holiday, and company-wide extended PTO is taking
place in this cycle.

You may be asking, how close is the service worker e10s rewrite?  Have you
guys made any progress?

Let me provide a brief update of where we are:

- The main blocker has been bug 1293277 as it is necessary to provide
cross-process primitives we can use in ServiceWorkerManager and necko.
- I am now splitting off patches from the mega-patch in bug 1293277 and
landing them as they are reviewed.
- I expect bug 1293277 to 100% be done in FF59 and hopefully before the
holiday.
- We have also extricated the parent-side service worker interception code
from the main http cache path in bug 1391693.  This will make it easier to
refactor interception as it isolates us from some necko complexity.
- After bug 1293277 is done there will be additional work to use the
primitives throughout the ServiceWorkerManager to enable it to live
cross-process.
- We also need to update prototype work to do service worker launch and
event dispatch remotely from the parent process.
- We can then switch to performing all service worker interception and life
cycle management in the parent process.
- There will also probably be a reasonably long tail of stability and
performance issues to fix.  Fortunately we have a pretty good test suite to
avoid functional regressions.

At the end of the day we all would like this complete so we could enable in
ESR, but I think the amount of work remaining is challenging given the
holiday/all-hands cycle.  Realistically we should plan on service workers
being disabled in FF59 ESR.

Please let me know if you have any 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: CSP Violation DOM Events

[James Graham]

On 17/11/17 16:06, Daniel Veditz wrote:
On Fri, Nov 17, 2017 at 2:01 AM, James Graham > wrote:


Do we have cross-browser (i.e. web-platform) tests covering this
feature?


We fail many of the existing CSP web platform tests, despite having 
implemented most of the features, because they were written to use the 
violation events to check the results.​


Is that an issue with our implementation or something we should fix in 
the tests? In either case it seems problematic to have such a feature 
and no way of checking for compatibility with other implementations.

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

Re: Firefox Browser performance test

[Nicholas Hurley]

In addition to Talos, you may also want to look into
http://www.webpagetest.org/ which has a lot more info available in terms of
packet captures, etc, but has the downside that you can't use custom builds
(you can change preferences, though).

On Fri, Nov 17, 2017 at 7:02 AM,  wrote:

> Hello,
>
> I would like to test Firefox browser performance test - using default
> settings and using customized settings(about:config).
>
> Performance parameters I am looking :
> 1. Time - required to open webpage
> 2. Number of packets transferred between the browser and website - while
> opening
>the first page of the website on the browser (client side)
> 3. Size of each packet - transferred between the browser and website -
> while
>opening the first page of the website on the browser (client side).
> 4. Any other method (or parameter) which needs to be considered for
> performance
>testing.
>
> Can you suggest me any tool or benchmark tool - that will help me.
>
> Waiting for the reply.
>
> Thanks & Regards
>
> Harshad
> ___
> 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: Intent to ship: CSP Violation DOM Events

[smaug]

On 11/17/2017 12:55 AM, Chung-Sheng Fu wrote:

Content Security Policy suggests Security Policy Violation DOM Events [1].
In case any of the directives within a policy are violated, such a
SecurityPolicyViolationEvent is generated and sent out to a reporting
endpoint associated with the policy. We are working on implementing those
violation events here [2] and plan to ship them within Firefox 59.

Thanks,

Chung-Sheng Fu, Christoph Kerschbaumer

[1] https://w3c.github.io/webappsec-csp/#violation-events

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1037335




Looks like there are quite a few spec issues still. Probably better to get 
those fixed first and then
update our implementation.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSP Violation DOM Events

[Daniel Veditz]

On Fri, Nov 17, 2017 at 2:01 AM, James Graham 
wrote:

> Do we have cross-browser (i.e. web-platform) tests covering this feature?


We fail many of the existing CSP web platform tests, despite having
implemented most of the features, because they were written to use the
violation events to check the results.​
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Firefox Browser performance test

[Dustin Mitchell]

Firefox has an extensive performance testing framework, called Talos

https://wiki.mozilla.org/Buildbot/Talos might be a good place to start.

Dustin

2017-11-17 10:02 GMT-05:00  :
> Hello,
>
> I would like to test Firefox browser performance test - using default 
> settings and using customized settings(about:config).
>
> Performance parameters I am looking :
> 1. Time - required to open webpage
> 2. Number of packets transferred between the browser and website - while 
> opening
>the first page of the website on the browser (client side)
> 3. Size of each packet - transferred between the browser and website - while
>opening the first page of the website on the browser (client side).
> 4. Any other method (or parameter) which needs to be considered for 
> performance
>testing.
>
> Can you suggest me any tool or benchmark tool - that will help me.
>
> Waiting for the reply.
>
> Thanks & Regards
>
> Harshad
> ___
> 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

Firefox Browser performance test

[harshad . wadkar]

Hello,

I would like to test Firefox browser performance test - using default settings 
and using customized settings(about:config).

Performance parameters I am looking :
1. Time - required to open webpage 
2. Number of packets transferred between the browser and website - while 
opening 
   the first page of the website on the browser (client side)
3. Size of each packet - transferred between the browser and website - while 
   opening the first page of the website on the browser (client side).
4. Any other method (or parameter) which needs to be considered for performance 
   testing.

Can you suggest me any tool or benchmark tool - that will help me.

Waiting for the reply.

Thanks & Regards

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

Re: Still-supported cases of out-of-tree XPCOM code?

[Valentin Gosu]

Trying to land bug 1407679, which merges nsIIOService2 into nsIIOService,
triggered some crashes on Android.
It seems the hostutils is also affected by XPCOM changes. Bug 1415242
updated it and fixed the crashes.

On 15 November 2017 at 17:35, Jonathan Kingston  wrote:

> > Code search wouldn't have helped *this* case, but considering how
> useful https://dxr.mozilla.org/addons/ has been previously, the notion
> of there still existing out-of-tree XPCOM callers but them being dark
> matter code search-wise worries me.
>
> This was failing for quite some time, we kept ahead of the failures when
> firefox was radically changing this.
>
> I agree a test suite would help for these addons for stability going
> forward as maintaining this for containers was a hard task.
>
> I would like to re-iterate what Baku said, there was a log failure that
> wasn't picked up and was thought to be the failure. It however wasn't and
> the actual bug was in central impacting Nightly container users also.
>
> > If the file is needed for <56, why does it even run in 57 or 58?
>
> The code shouldn't run for those versions, there was an import for all
> versions which caused an error however didn't even prevent the rest of the
> file from loading which is used to make the embedded extension load.
>
> On Wed, Nov 15, 2017 at 4:31 PM, Kris Maglione 
> wrote:
>
> > On Wed, Nov 15, 2017 at 04:12:06PM +0200, Henri Sivonen wrote:
> >
> >> On Wed, Nov 15, 2017 at 3:16 PM, Andrea Marchesini
> >>
> >>> This is why we had this issue. It should not be impossible for a
> >>> 'standard'
> >>> webextension to generate such mess.
> >>>
> >>
> >> How many Mozilla-signed special extensions are there? Does an analog
> >> of https://dxr.mozilla.org/addons/ exist for searching their code? Is
> >> there a CI system testing that the continue to work?
> >>
> >
> > The situation is pretty bad at this point. Ideally, all XPCOM add-ons
> that
> > we support should run tests in treeherder on checkin, both for add-on
> > changes and m-c changes. But as of now, most system add-ons, Test Pilot
> > add-ons, and SHIELD studies are hosted on Github and do their own ad-hoc
> > testing, mostly using Node-ish testing frameworks.
> >
> > There's also no standard place to host or index all of this add-on code,
> > or even to get a list of what such add-ons exist. At one point, I asked
> for
> > all SHIELD add-ons to at least be hosted in the same Github organization.
> > The same should probably go for all other Mozilla-signed add-ons. That
> > would at least give us a single place to find any XPCOM add-on code that
> we
> > still support.
> >
> > In the mean time, though, as far as I'm concerned, the maintainers of
> > those add-ons are responsible for dealing with breakage that results from
> > not having in-tree tests and a standard place to search that code. If
> > you're removing legacy XPCOM functionality, all you should need to care
> > about is whether treeherder is green.
> >
> > ___
> > 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: Intent to ship: CSP Violation DOM Events

[Ethan Tseng]

On Fri, Nov 17, 2017 at 6:01 PM, James Graham 
wrote:

> On 17/11/17 05:55, Chung-Sheng Fu wrote:
>
>> Content Security Policy suggests Security Policy Violation DOM Events [1].
>> In case any of the directives within a policy are violated, such a
>> SecurityPolicyViolationEvent is generated and sent out to a reporting
>> endpoint associated with the policy. We are working on implementing those
>> violation events here [2] and plan to ship them within Firefox 59.
>>
>
> Do we have cross-browser (i.e. web-platform) tests covering this feature?


Yes we do.
The web-platform tests are in the folder
testing/web-platform/meta/content-security-policy/.
Bug 1037335  added
several tests for this feature and modified a bunch of tests to make them
fit in it.


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

Re: Intent to ship: CSP Violation DOM Events

[James Graham]

On 17/11/17 05:55, Chung-Sheng Fu wrote:

Content Security Policy suggests Security Policy Violation DOM Events [1].
In case any of the directives within a policy are violated, such a
SecurityPolicyViolationEvent is generated and sent out to a reporting
endpoint associated with the policy. We are working on implementing those
violation events here [2] and plan to ship them within Firefox 59.


Do we have cross-browser (i.e. web-platform) tests covering this feature?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform