Re: Intent to unship: system SQLite support on Linux (--enable-system-sqlite)

2020-02-24 Thread Marco Bonardo 
The unship patch was just merged in mozilla-central in bug 1611386.

Marco

On Thu, Feb 6, 2020 at 4:11 PM Marco Bonardo  wrote:

> The Storage support team intends to remove support for building
> Mozilla-based applications using the system provided SQLite library on
> Linux (--enable-system-sqlite).
>
>
>
> When: After the next mozilla-central merge to Nightly 75, February 10th.
> We plan to unship support during the 75 cycle.
>
>
>
> Where: https://bugzilla.mozilla.org/show_bug.cgi?id=1611386
>
> Why:
>
>1.
>
>We have limited resources available to us. Developing new features
>that touch SQLite low level APIs have often required additional resources
>to ensure system SQLite keeps working; we are at a point where we can't
>afford those development costs.
>2.
>
>We had bugs due to it and the most recent of which, tracked in
>https://bugzilla.mozilla.org/show_bug.cgi?id=1607902, is due to a
>mistake we made in relying on some Sqlite internal details. The result of
>that, due to supporting system Sqlite, is that we requested the Sqlite team
>to undo some code improvements in a .1 release, and, in spite of that,
>older Firefox versions on a specific new Sqlite version will crash forever.
>We don't want to be in this situation where the Sqlite team can't improve
>their product freely.
>3.
>
>There is risk of losing users due to the kind of crashing bugs this
>can cause, because not everyone would be able to connect the misbehavior
>with the update of an external library, that may have been updated along
>with other packages updates. And downgrading Sqlite may not be an option if
>another software requires the new version instead.
>4.
>
>For quite some time we ended up enforcing our Sqlite preferences onto
>the system library (things like ‘secure_delete’ or ‘fts’, for example);
>addressing those cases requires time and resources. We don't want to
>enforce our specific choices.
>5.
>
>Our Web Storage team will soon start working with Sqlite encryption,
>in a way that may not be compatible with system Sqlite. Again, having to
>cope with the system library would mean a lot of additional effort, and
>more requirements for system Sqlite that may not be well digested.
>6.
>
>We have our own custom memory allocator, and hooking it up has
>complications we'd prefer to avoid, if possible.
>7.
>
>The benefits of using system SQLite so far have been minimal. We
>wanted to be good citizens by sharing as much as possible with the system,
>as it was common practice. Today the historical packaging strategies on
>Linux systems are evolving with the introduction of new packaging systems
>(Snap, Flatpak, for example) that changed the relationship with
>dependencies by packing them up with the main application.
>The remaining benefits (e.g. package size, memory) are negligible on
>today's hardware.
>The security benefits we get because the system Sqlite may be more
>up-to-date are minimal, because we don't expose Sqlite to Web content, nor
>to add-ons. Additionally, we actively track and test every new Sqlite
>release and apply them as soon as possible.
>
>
>
> Thanks,
>
> Marco
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to prototype: :focus-visible pseudo-class.

2020-02-24 Thread Emilio Cobos Álvarez 

Hi,

In bug 1617600 I plan to land a patch to implement :focus-visible, 
behind a pref, on by default on Nightly / Early Beta.


Summary: Implement the :focus-visible pseudo-class, which is like 
:focus, but with heuristics about when _not_ to show focus rings, for 
example.


This is similar in intent to :-moz-focusring, but not in behavior. In 
particular, :-moz-focusring is stateful, and all-or-nothing. Once you've 
tab-navigated in a window, _everything_ shows focus rings. See comments 
in bug 1445482 about why that doesn't match developers' expectations.


For now the heuristic I'm going to implement is quite simple: We don't 
match the pseudo-class if focused via mouse / touch, and we do 
otherwise. This heuristic will almost-surely need tweaking. Simple 
example: we probably want to match the pseudo-class unconditionally for 
editable elements and such. By providing an early implementation, the 
idea is for Nightly / Dev Edition users and developers to file bugs 
against it as needed.


We should consider also add a preference to always match focus-visible 
users with higher accessibility needs, etc... I'll make sure to check 
with the a11y team about this. This all should be pretty easy to implement.


The idea here is that we could eventually alias our :-moz-focusring 
pseudo-class to be :focus-visible.


Bug: Main bug for the feature is bug 1445482. Bug for the initial 
implementation is above.


Pref: layout.css.focus-visible.enabled

Standard: https://drafts.csswg.org/selectors-4/#the-focus-visible-pseudo

Platform coverage: all

DevTools bug: I filed bug 1617608 to allow toggling the pseudo-class. I 
don't think there's much else needed but let me know if you think otherwise.


Other browsers:

 * WebKit: Not implemented yet: 
https://bugs.webkit.org/show_bug.cgi?id=185859


 * Chromium: Behind a flag, work ongoing in 
https://bugs.chromium.org/p/chromium/issues/detail?id=817199


web-platform-tests: There are some basic tests in 
https://wpt.fyi/results/css/selectors?label=master=experimental=focus-visible 
(with some manual tests in that directory as well). This feature 
involves heuristics so not all the tests may qualify as non-tentative 
WPT (though I plan to land our tests for features that developers 
request with .tentative suffix).


Secure contexts: Not restricted to secure context, as many related CSS 
features.


Is this feature enabled by default in sandboxed iframes? Yes

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

Re: Android tests - do not forget logcat!

2020-02-24 Thread Homer Simpson 
Le vendredi 14 février 2020 20:48:37 UTC+1, Geoffrey Brown a écrit :
> Lately it feels like there is more activity around running, investigating,
> and fixing Android automated tests -- that's great to see!
> 
> When looking at logs from automated test logs, be aware that there are
> differences between desktop and Android. Some messages dumped to standard
> output will appear in the desktop test log, but not on Android: They likely
> appear in the logcat instead. Logcat also provides additional diagnostic
> logging from geckoview, as well as logging from the OS and other apps
> running on the test device. It is a complicated, comprehensive account of
> what is happening on the device -- often essential to understanding test
> failures.
> 
> All Android test tasks have the full logcat attached as a separate
> artifact, visible in the treeherder Job Details pane and also in the Log
> Viewer. Look for "*artifact uploaded:* logcat-.log".

My life is donut
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to prototype: Document as explicit root of an intersection observer

2020-02-24 Thread Frédéric Wang 
Summary: This is an enhancement to the IntersectionObserver API.
Currently, it is possible to use the top level document (implicit root)
or to specify an Element (e.g. {root: document.scrollingElement}). None
of these options provides a way to specify a root corresponding to the
bounding box of an iframe's window. This proposal is about allowing an
explicit Document root, in order to cover that case.

Original intent-to thread:
https://groups.google.com/forum/#!searchin/mozilla.dev.platform/intersectionobserver/mozilla.dev.platform/YdKTMvQygl0/cl2vdYt3BgAJ

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1617154
 https://bugzilla.mozilla.org/show_bug.cgi?id=1381574 (meta bug)

Standard:
https://w3c.github.io/IntersectionObserver (specification)
https://github.com/w3c/IntersectionObserver/issues/372 (public discussion)

Platform coverage: All

Preference: dom.IntersectionObserverExplicitDocumentRoot.enabled

DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1617526
  https://bugzilla.mozilla.org/show_bug.cgi?id=1347849

Other browsers:
* WebKit:
  intent emailed
https://lists.webkit.org/pipermail/webkit-dev/2020-February/031087.html
  considering https://bugs.webkit.org/show_bug.cgi?id=208047
* Blink:
  intent emailed
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/6dOOw2vu1is
  shipped since version 81
https://chromium-review.googlesource.com/c/chromium/src/+/2015676

web-platform-tests:
https://w3c-test.org/intersection-observer/document-scrolling-element-root.html

Secure contexts: Same as IntersectionObserver
Is this feature enabled by default in sandboxed iframes: Same as
IntersectionObserver

As mentioned in the original intent-to thread, the root can be in a
different-origin document so there is some security aspect to consider
here. AFAIK, the proposal does not make the situation worse though. I
can't find any conclusion on the security aspect in the original
intent-to thread, so I guess someone more knowledgeable than me on this
should comment.

-- 
Frédéric Wang
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[desktop] Bugs logged by Desktop Release QA in the last 7 days

2020-02-24 Thread Mihai Boldan 

Hello,

Here's the list of new issues found and filed by the Desktop Release QA 
team in the last 7 days.
Additional details on the team's priorities last week, as well as the 
plans for the current week are available at: https://tinyurl.com/wjbzdf2.

Bugs logged by Desktop Release QA in the last 7 days:
*
*Firefox: Address Bar
* NEW - https://bugzil.la/1616002 - When default zoom level is changed a 
“100%” flash is displayed in address bar after restarting Firefox


Firefox: Bookmarks & History
* NEW - https://bugzil.la/1616061 - The site preview is not displayed 
the bookmark is made via context meniu


Firefox: Enterprise Policies
* ASSIGNED - https://bugzil.la/1616007 - Policies set via GPO can be 
bypassed/canceled by using an invalid policies.json file


Firefox: Installer
* NEW - https://bugzil.la/1616834 - Stub Installer Paveover update 
prompt is not displayed


Firefox: Preferences
* ASSIGNED - https://bugzil.la/1616008 - When using very high (200+%) 
text-only zoom in the preferences / options, text in dropdowns 
(menulists), buttons and other UI elements escapes the bounding box / 
background for the element


Firefox: Protections UI
* NEW - https://bugzil.la/1616508 - If in one tab ETP is OFF, the switch 
moves from OFF position to ON while navigating between two tabs


Core: DOM: Push Notifications
* NEW - https://bugzil.la/1617164 - No notification displayed when they 
are allowed through “Change whether you can receive notifications from 
the site” button


Core: ImageLib
* NEW - https://bugzil.la/1616765 - Large PNG image is not completely 
rendered on Firefox


Core: Panning and Zooming
* NEW - https://bugzil.la/1616593 - [Ubuntu] Scrolling is broken on 
“Onscroll latency” test page


Core :Widget: Cocoa
* NEW - https://bugzil.la/1616290 - Inconsistent naming of the "Exit 
fullscreen" touch bar button


Core: Widget: Win32
* RESOLVED FIXED - https://bugzil.la/1616000 - Push notification are no 
longer displayed


Toolkit: Video/Audio Controls
* NEW - https://bugzil.la/1617115 - [Ubuntu] PiP gets smaller if you 
navigate back and forth between videos with different formats
* NEW - https://bugzil.la/1617123 - [macOS] - PIP controls overlap on 
resize to min size
* NEW - https://bugzil.la/1617125 - Youtube - PIP frame remains on page 
if accessing a video from website sub-page
* NEW - https://bugzil.la/1617134 - [Ubuntu] After using the keyboard 
shortcut to open PiP the focus remains on the site, not on PiP
* NEW - https://bugzil.la/1617135 - If PiP is in focus the keyboard 
combination CTRL+SHIFT+] doesn't work for closing the frame.


Web Compatibility: Desktop
* NEW - https://bugzil.la/1616588 - Scrolling is broken on kaipoche.co

Mozilla: Contain-facebook
* OPEN - #584  - 
Certain strings are not displayed as bolded on FBC doorhanger
* OPEN - #585  - 
Door hangers are not displayed for "Allow" and "Remove" functions


This is available as a Bugzilla bug list as well: 
https://tinyurl.com/w3eszkr.


Regards,
Mihai Boldan


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