Re: How can I get SOCKS settings params of Firefox?

[Karl Tomlinson]

I don't know how well GConf is supported by more recent GNOME
versions.  I assume GSettings support was added to
nsUnixSystemProxySettings because GConf was to be no longer
supported, but the crash reporter uses separate code.

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

http://searchfox.org/mozilla-central/rev/8a6a6bef7c54425970aa4fb039cc6463a19c0b7f/toolkit/system/unixproxy/nsUnixSystemProxySettings.cpp#445

A potentially better solution is proposed in
https://bugzilla.mozilla.org/show_bug.cgi?id=1333125
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement: DevTools onboarding page

[Julian Descottes]

# Summary
When users try to open DevTools for the very first time, we would like to
prompt
them for a confirmation first, displayed in an onboarding page.

The main goal is to inform new users about DevTools, and avoid accidental or
malicious usage.

A secondary goal is performance related. Some code paths can be optimized if
DevTools are disabled. For example, we can turn console.log calls into
“no-ops”,
see https://bugzilla.mozilla.org/show_bug.cgi?id=1382377 .

Onboarding is also a requirement of the project to move Devtools into an
addon,
which will reduce Firefox’s installer size and eventually will allow the
team to
use GoFaster as shipping mechanism.


# UI



The onboarding page will be opened in a tab after a user triggers any
DevTools
entry point (menu item, key shortcut, etc…). It will explain why it is being
displayed and what DevTools are, and it will have a button to "enable"
DevTools.
After the user clicks on the "enable" button, we will display a confirmation
message and more detailed information about DevTools. After that, the
onboarding
page will not be displayed anymore.


# Additional information

We will assess the impact with a shield study on the Beta channel, measuring
the click-through rate of the onboarding page and engagement metrics with
the
various panels. Our hypothesis is that this will not block developers from
using
the tools but cuts out accidental usage.

We need to define which profiles are exposed to the onboarding. Current
plan:
  - Nightly and DevEdition: Developer tools enabled by default, onboarding
flow
disabled
  - Beta and Release: onboarding flow enabled for profiles that never used
DevTools. We want to detect such profiles by looking at existing
preferences
or recent telemetry (will be determined with a follow-up study).

The onboarding flow should also be disabled when users pass a DevTools
specific
command line argument to start Firefox (e.g. --devtools, --jsdebugger etc…).

The feature will be behind a preference: "devtools.onboarding.enabled".


# Bugs and documents

Meta bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1408969

Initial discussion and mockups at
https://docs.google.com/document/d/1ku6Jn12XdTFNno0phhLjlBD2
H43k5NYswALYnA_UVBA/edit#heading=h.czol3ydlw299



# Target release

We plan to perform a study in Beta 58, and will decide about a target
release
depending on the results.


# Other browsers

- Safari completely hides developer options unless explicitly turned on in
the
preferences.
- Edge hides the Inspect Element and View source context menu items if
F12 Developer Tools were never used. They also show an introductory message
when
Developer Tools start for the first time.
- Chrome doesn't implement anything similar.


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

Threadsafe URLs - MozURL

[Valentin Gosu]

Hi everyone,

Threadsafe URLs have been high on everybody's wishlist for a long while.
The fact that our nsIURI implementations weren't thread safe meant that
hacks had to be used to use a URI off the main thread, such as saving it as
a string, or bouncing back to the main thread whenever you had to use the
URI in any way.

A few weeks ago we landed MozURL. This is an immutable threadsafe wrapper
for rust-url. While it's not yet ready to fully replace our existing URL
implementations, it's good enough to avoid using the hacks I just mentioned.

For examples of how to use it go to the header file [1] or the gtests [2]

Work is also under way to provide a threadsafe implementation of nsIURI
that we eventually hope to replace our other URI parsers, and to improve
the rust-url parser to be faster than our current nsStandardURL
implementation [3].

[1] http://searchfox.org/mozilla-central/source/netwerk/base/MozURL.h
[2]
http://searchfox.org/mozilla-central/source/netwerk/test/gtest/TestMozURL.cpp
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1394906#c2
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Threadsafe URLs - MozURL

[Anne van Kesteren]

On Mon, Oct 23, 2017 at 4:01 PM, Valentin Gosu  wrote:
> A few weeks ago we landed MozURL. This is an immutable threadsafe wrapper
> for rust-url.

What is the plan for these issues:

  https://github.com/servo/rust-url/issues/163
  https://github.com/servo/rust-url/issues/290

I'm rather worried that no serious effort to align with the standard
has taken place for close to two years. Quite a few things changed,
especially in response to feedback from the implementations by Safari,
Node.js, and jsdom. And also in response to work undertaken in
Firefox.


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

Re: Threadsafe URLs - MozURL

[Jeff Muizelaar]

For the curious among us, what made nsIURI not thread safe in the first place?

-Jeff

On Mon, Oct 23, 2017 at 10:01 AM, Valentin Gosu  wrote:
> Hi everyone,
>
> Threadsafe URLs have been high on everybody's wishlist for a long while.
> The fact that our nsIURI implementations weren't thread safe meant that
> hacks had to be used to use a URI off the main thread, such as saving it as
> a string, or bouncing back to the main thread whenever you had to use the
> URI in any way.
>
> A few weeks ago we landed MozURL. This is an immutable threadsafe wrapper
> for rust-url. While it's not yet ready to fully replace our existing URL
> implementations, it's good enough to avoid using the hacks I just mentioned.
>
> For examples of how to use it go to the header file [1] or the gtests [2]
>
> Work is also under way to provide a threadsafe implementation of nsIURI
> that we eventually hope to replace our other URI parsers, and to improve
> the rust-url parser to be faster than our current nsStandardURL
> implementation [3].
>
> [1] http://searchfox.org/mozilla-central/source/netwerk/base/MozURL.h
> [2]
> http://searchfox.org/mozilla-central/source/netwerk/test/gtest/TestMozURL.cpp
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1394906#c2
> ___
> 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: Threadsafe URLs - MozURL

[Valentin Gosu]

On 23 October 2017 at 16:30, Jeff Muizelaar  wrote:

> For the curious among us, what made nsIURI not thread safe in the first
> place?
>

One of the factors was that as an IDL nsIURI could also be implemented by
JS code in addons, which could only run on the main thread.


> -Jeff
>
> On Mon, Oct 23, 2017 at 10:01 AM, Valentin Gosu 
> wrote:
> > Hi everyone,
> >
> > Threadsafe URLs have been high on everybody's wishlist for a long while.
> > The fact that our nsIURI implementations weren't thread safe meant that
> > hacks had to be used to use a URI off the main thread, such as saving it
> as
> > a string, or bouncing back to the main thread whenever you had to use the
> > URI in any way.
> >
> > A few weeks ago we landed MozURL. This is an immutable threadsafe wrapper
> > for rust-url. While it's not yet ready to fully replace our existing URL
> > implementations, it's good enough to avoid using the hacks I just
> mentioned.
> >
> > For examples of how to use it go to the header file [1] or the gtests [2]
> >
> > Work is also under way to provide a threadsafe implementation of nsIURI
> > that we eventually hope to replace our other URI parsers, and to improve
> > the rust-url parser to be faster than our current nsStandardURL
> > implementation [3].
> >
> > [1] http://searchfox.org/mozilla-central/source/netwerk/base/MozURL.h
> > [2]
> > http://searchfox.org/mozilla-central/source/netwerk/test/
> gtest/TestMozURL.cpp
> > [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1394906#c2
> > ___
> > 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: Threadsafe URLs - MozURL

[Valentin Gosu]

On 23 October 2017 at 16:21, Anne van Kesteren  wrote:

> On Mon, Oct 23, 2017 at 4:01 PM, Valentin Gosu 
> wrote:
> > A few weeks ago we landed MozURL. This is an immutable threadsafe wrapper
> > for rust-url.
>
> What is the plan for these issues:
>
>   https://github.com/servo/rust-url/issues/163
>   https://github.com/servo/rust-url/issues/290
>
> I'm rather worried that no serious effort to align with the standard
> has taken place for close to two years. Quite a few things changed,
> especially in response to feedback from the implementations by Safari,
> Node.js, and jsdom. And also in response to work undertaken in
> Firefox.
>

This is indeed a concern, but from what I can tell the only barrier to
improving rust-url is finding the people to work on it. I intend to devote
some time to this in the next few weeks.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Threadsafe URLs - MozURL

[Boris Zbarsky]

On 10/23/17 10:30 AM, Jeff Muizelaar wrote:

For the curious among us, what made nsIURI not thread safe in the first place?


There were several aspects to this:

1)  Constructing a URI object.  This needed a protocol handler, which 
could be implemented in JS by extensions.  With XPCOM extensions gone, 
we probably still need to audit our protocol handlers to ensure they're 
threadsafe.


2)  Necko caches the protocol handler for a scheme after the first time 
you get it.  This cache is obviously shared mutable global state, and is 
not threadsafe at the moment.


3)  The URI could be implemented in JS by extensions.  Again, with that 
gone we need to audit our built-in URI implementations to ensure they're 
threadsafe.  Some of this work (and fixing the threadsafety issues it 
uncovered) happened in 
https://bugzilla.mozilla.org/show_bug.cgi?id=1344751 already.


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

Re: De-XBL Plans

[Brian Grinstead]

> On Oct 22, 2017, at 3:35 AM, smaug  wrote:
> 
> On 10/21/2017 11:45 PM, Yura Zenevich wrote:
>> I would also like to bring to the team's attention another force worth
>> being on the radar (in terms of "forces on the system") - accessibility.
>> One theme that seems to consistently happen with re-writes such as the ones
>> from xul to React is regressions in terms of accessibility of newly
>> re-written components.
> 

Thanks, I’ve submitted a PR to the plan to add this point.

> Yeah, this is important. I would imagine custom elements in XUL (which might 
> then internally use shadow DOM too) would implement the same
> a11y interfaces what XBL implements now.

I agree - if we migrate the logic inside of bindings (i.e. formatAccessKey on 
) and continue to use XUL Elements this should limit the risk of 
regressions. Two places we should take a closer look at:

1) Ensure that anonymous XBL content is not somehow handled differently from an 
accessibility standpoint compared to normal DOM children in a Custom Element 
(or content inside Shadow DOM)
2) We may need to emulate the [role] attribute on a binding definition, which 
does map to some accessibility code. Do we need to change the way we create the 
appropriate Accessible class for Custom Elements? It does look at 
XBLBindingRole as a way to choose which role to assign (i.e. role=”xul:toolbar” 
on the binding definition). For Custom Elements, it may be easier to use tag 
names to determine the role, or somehow store it in the custom element registry 
to avoid setting a ‘role’ attribute on each node during the connectedCallback.
** 
https://dxr.mozilla.org/mozilla-central/rev/69e24c678a28dc46a4c1bda3ff04b2f6106ff71a/toolkit/content/widgets/button.xml#12
** 
https://dxr.mozilla.org/mozilla-central/rev/69e24c678a28dc46a4c1bda3ff04b2f6106ff71a/accessible/base/nsAccessibilityService.cpp#1380

>> 
>> thanks,
>> yura
>> 
>> On Sat, Oct 21, 2017 at 6:14 AM, Philipp Kewisch  wrote:
>> 
>>> On 10/20/17 7:47 PM, Dave Townsend wrote:
 For some time now we've been talking about moving away from XUL and XBL.
 The browser architecture team has been hard at work figuring out how to
>>> go
 about doing that and we're ready to share the first of our proposals more
 widely. We have developed a plan to remove XBL from Firefox. It's been
 through a successful design review with some of the key engineers and now
 is the time for more comments if you have them. We're planning to start
>>> some
 of the work this quarter with it really ramping up next quarter.
 
 Take a look at the plan
 >> text/0007-xbl-design-review-packet.html>
 and let us know what you think. There are a couple of areas where we are
 still investigating concerns:
>>> 
>>> I very much welcome this plan, especially the fact that Web Components
>>> is part of the replacement. Last time I asked, it sounded like Web
>>> Components was still on the way of being reimplemented and pending some
>>> spec work. In following the webcomponents bug I see there has been
>>> constant progress.
>>> 
>>> Nevertheless, I'd appreciate if someone could comment on how far along
>>> the Web Components implementation is. Is it now following the agreed
>>> upon version of the spec (I suspect yes), and is the implementation
>>> stable enough that you would consider it ready to ship? What is the next
>>> big milestone for Web Components?
>>> 
>>> Thunderbird/Lightning uses a lot of XBL components as well that I would
>>> love to get rid of, I am looking forward to making things more
>>> compatible with the future.
>>> 
>>> Thanks,
>>> Philipp
>>> 
>>> 
>>> 
>>> ___
>>> 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

Move assignment and constructors for ns[C]String

[Nika Layzell]

Hello everyone!

Bug 1377351 landed on central recently, and adds move assignment operators
and constructors to ns[C]String. These operators attempt to re-use
allocations when possible and can reduce the cost of copying strings around.

This could be used in some situations to improve assignment to nsString
fields in structs, for example, this call will avoid allocating & using
reference counts in more situations than the equivalent code using `const
nsAString&`:

void
SetFoo(nsAString&& aFoo)
{
  mFoo.Assign(Move(aFoo));
}

In addition, this can be used to save some work when returning using an
outparameter:

void
GetFoo(nsAString& aOut)
{
  // Somehow get a string value we want to return
  nsString returnValue = ...;
  aOut.Assign(Move(returnValue));
}

After using one of these move assignment operators, the original string
will be truncated. This functionality is also exposed to rust code through
the `take_from` method.

Consider moving ns[C]String values in the future when assigning to avoid
unnecessary work.

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

[Firefox Desktop] Issues found: October 16th to October 20th

[Cornel Ionce]

Hi everyone,

Here's the list of new issues found and filed by the Desktop Release QA 
Team last week, *October 16 - October* *20*  (week 42).


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
*

ID  Summary Product Component   Is a regression 
Assigned to
1409043 
[Linux] Onboarding tour highlight is faulty
Firefox
Tours
YES NOBODY
1409377 
Scrollbar overlaps the keyboard shortcuts in the Hamburger menu
Firefox
Menus
	YES 
 
	NOBODY
1409640  	[Linux] Dropdown arrow for 
Applications is barely visible

Firefox
Preferences
	YES 
 
	NOBODY

1409661
 	[57] The Firefox firstrun page is set as a 
highlight when first opening the AS New Tab Page

Firefox
Activity Streams: Newtab
TBD NOBODY
1409662 
Entries from Fonts menu do a refresh every time the menu is opened
Firefox
Preferences
	YES 
 
	NOBODY

1409696 
Line that marks the end of output field from Certificate Manager is 
missing
Firefox
Preferences
	YES 
 
	NOBODY

1409710 
Misalignment of buttons from Firefox Accounts page
Firefox
Preferences
NO  NOBODY
1409715 
A top site can also be displayed in the Highlights section
Firefox
Activity Streams: Newtab
NO  NOBODY
1409731 
	Time values cannot be changed with arrow keys while using "NVDA" screen 
reader

Core
Layout: Form Controls
NO  NOBODY
1409785 
Firefox crashes after restart/shutdown
Toolkit
DOM: Content Processes
TBD NOBODY
1410056 
Toolbar dropdown is not visible in full screen mode on Mac OS X
Firefox
Toolbars and Toolbar Customization
	YES 
 
	NOBODY

1410075 
	Multiple issues generated by 
https://mondaynote.com/teslas-new-car-smell-315c72c955d3 Pocket 
recommendation

Firefox
Activity Streams: Newtab
NO  NOBODY
1410114 
	The "Bookmarks Toolbar" option from the customize panel is misplaced in 
full screen mode

Firefox
Toolbars and Customization
	YES 
 
	Mike de Boer 

1410180
   The top sites prioritization is faulty
Firefox
Activity Streams: Newtab
TBD NOBODY
1410408 
Changing the background and text colors from about:preferences is faulty
Firefox
General
NO  NOBODY
1410442 
Useless horizontal scrollbar shown at minimum window width
Firefox
Activity Streams: Newtab
TBD NOBODY
1410450 
The New Tab Preferences menu's width doesn't adapt to the window's width
Firefox
Activity Streams: Newtab
TBD NOBODY

*
NIGHTLY CHANNEL**
*
ID  Summary Product Component   Is a regression 
Assigned to
1409033  	Cannot scroll using two fingers in 
Library window

Core
Widget: Win32
NO  NOBODY
1398101 
	[Form Autofill] Credit card autofill doesn't work on some of the main 
shopping sites

Toolkit
Form Manager
NO  Sean Lee 
1409366 
	[Form Autofill] Credit card expiration Year is placed above the payment 
section whe

Intent to implement: scroll-boundary-behavior

[Botond Ballo]

Summary:
  A CSS property that allows web developers to control what scroll
  boundary actions performed by the browser (such as scroll handoff
  to a parent scrollable element, visual overscroll effect, swipe
  navigation, etc.) should apply to a scrollable element.

Tracking bug:
  https://bugzilla.mozilla.org/show_bug.cgi?id=951793

Draft spec:
  https://wicg.github.io/scroll-boundary-behavior/

Platform coverage:
  The CSS property will be supported on all platforms. The browser's
  default boundary actions may vary from platform to platform (for
  example, Firefox currently shows a visual overscroll effect on
  Android but not on desktop platforms).

Estimated target release:
  Behind a pref: Firefox 58 (estimated)
  Enabled by default: TBD

Preference behind which this will be implemented:
  layout.css.scroll-boundary-behavior.enabled

DevTools support:
  I don't believe any special support is required beyond adding the
  property to the list of properties surfaced by the inspector.

Support by other browser engines:
  Blink: Yes, will ship in Chrome 63 [1]
  Edge: Public support [2]
  WebKit: No public signals

Tests:
  The Blink implementers have upstreamed a web-platform-test [3].
  I plan to look into getting that to run on Firefox. Additional test
  cases can be added to it if necessary.

Cheers,
Botond

[1] https://www.chromestatus.com/features/5734614437986304
[2] 
https://discourse.wicg.io/t/generic-scroll-chaining-prevention-mechanism-or-expand-standardize-ms-scroll-chaining/1811/5?u=majidvp
[3] 
http://searchfox.org/mozilla-central/rev/d30462037ffea383e74c42542c820cf65b2b144e/testing/web-platform/tests/cssom-view/scrollBoundaryBehavior-manual.html
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform