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

[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/wecwaxz.

Bugs logged by Desktop Release QA in the last 7 days:
*
*Firefox: General
* NEW - https://bugzil.la/1603397 - [Mac] Cancel button overlap the 
above message on Restart Firefox dropdown
* NEW - https://bugzil.la/1603691 - Extra telemetry events are generated 
after few minutes for Doh 1.3.0


Firefox: Protections UI
* NEW - https://bugzil.la/1602467 - Tracking protection remains active 
after navigating from links on data:text/html pages


Firefox: Security
* ASSIGNED - https://bugzil.la/1603478 - The 1.3.0 in-tree add-on 
doesn't respect user's set policies


Core: DOM: Security
* RESOLVED FIXED - https://bugzil.la/1602419 - “Security Error: Content 
at...” errors in browser console when visiting different websites


Core: WebRTC
* NEW - https://bugzil.la/1602724 - Crash in [@ arena_t::DallocSmall | 
free | audiounit_setup_stream]


Core: WebRTC: Audio/Video
* NEW - https://bugzil.la/1602722 - Disconnecting and reconnecting a USB 
headset in a webrtc call blocks its mic
* NEW - https://bugzil.la/1602723 - Removing audio jack while in 
talky.io call will make the video/audio to be out of sync


Core: WebRTC: Networking
* NEW - https://bugzil.la/1603474 - [Intermittent] Broken connectivity 
on herokuapp.com


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


Regards,
Mihai Boldan


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

Re: How to generate compatible firefox for all versions of linux system?

[Mike Hommey]

On Tue, Dec 10, 2019 at 10:54:39PM -0800, acnatar...@gmail.com wrote:
> Hi all, 
> 
> I had built a firefox on ubuntu 16.04 with GCC 5.4.0 and Glibc 2.23  from 
> Mozilla-central. Exported the package using "./mach package".  
> 
> firefox version 72.0a1.en
> 
> When  I try to launch the  exported firefox from another ubuntu machine with 
> same config   ubuntu 16.04, GCC 5.4.0 I was getting  an error   
> 
> 
> """ 
> XPCOMGlueLoad error for file /home/test/Documents/firefox/libxul.so:
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.22' not found 
> (required by /home/test/Documents/firefox/libxul.so)
> Couldn't load XPCOM
> """
> 
> This requires me to upgrade GCC in that machine in order to launch the 
> browser without errors.
> 
> I tried Firefox Nightly from Mozilla official releases works fine without 
> depending on the Glibc version. 
> 
> 
> What should I do to configure and build to make the exported firefox work on 
> other machines without upgrading the GCC version? 

You need to add `ac_add_options --enable-stdcxx-compat` to your
mozconfig. It's not guaranteed to work in all cases, though (it's
only tested in the build environment Mozilla uses for its builds)

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

Re: How to generate compatible firefox for all versions of linux system?

[Botond Ballo]

According to this page [1], the current minimum version of gcc
required to build Firefox trunk is 7.1.

If you need to build with gcc 5.4, you may need to build an older
release or esr branch rather than current trunk. I don't know if the
compiler requirements are documented on a per release basis anywhere,
but searching dev-platform should allow you to get an idea of when the
minimum required version was bumped.

Cheers,
Botond

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code

On Thu, Dec 12, 2019 at 8:36 AM  wrote:
>
> Hi all,
>
> I had built a firefox on ubuntu 16.04 with GCC 5.4.0 and Glibc 2.23  from 
> Mozilla-central. Exported the package using "./mach package".
>
> firefox version 72.0a1.en
>
> When  I try to launch the  exported firefox from another ubuntu machine with 
> same config   ubuntu 16.04, GCC 5.4.0 I was getting  an error
>
>
> """
> XPCOMGlueLoad error for file /home/test/Documents/firefox/libxul.so:
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.22' not found 
> (required by /home/test/Documents/firefox/libxul.so)
> Couldn't load XPCOM
> """
>
> This requires me to upgrade GCC in that machine in order to launch the 
> browser without errors.
>
> I tried Firefox Nightly from Mozilla official releases works fine without 
> depending on the Glibc version.
>
>
> What should I do to configure and build to make the exported firefox work on 
> other machines without upgrading the GCC version?
> ___
> 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 prototype: Character encoding detector

[Henri Sivonen]

On Mon, Dec 2, 2019 at 2:42 PM Henri Sivonen  wrote:
> 1. On _unlabeled_ text/html and text/plain pages, autodetect _legacy_
> encoding, excluding UTF-8, for non-file: URLs and autodetect the
> encoding, including UTF-8, for file: URLs.
>
> Elevator pitch: Chrome already did this unilaterally. The motivation
> is to avoid a situation where a user switches to a Chromium-based as a
> result of browsing the legacy Web or local files.

Feature #1 is now on autoland.

> # Preference

For file: URLs, I ended up not putting the new detector behind a pref,
because the file: detection code is messy enough even without
alternative code paths, and I'm pretty confident that the new detector
is an improvement for our file: URL handling behavior.

For non-file: URLs, the new detector is overall controlled by
intl.charset.detector.ng.enabled, which defaults to true, i.e.
detector enabled. When the detector is enabled, various old
intl.charset.* are ignored in various ways.

The detector is, however, disabled by default for three TLDs: .jp,
.in, and .lk. This can be overridden via the prefs
intl.charset.detector.ng.jp.enabled,
intl.charset.detector.ng.in.enabled, and
intl.charset.detector.ng.lk.enabled all three of which default to
false. (These prefs cannot enable the detector if
intl.charset.detector.ng.enabled is false)

In the case of .jp, the pre-existing Japanese-specific detector is
used. This avoids regressing how soon we start reloading if we detect
EUC-JP.

The detector detects encodings that are actually part of the Web
Platform. However, this can cause problems when a site expects the
page to be decoded as windows-1252 _as a matter of undeclared
fallback_ and expects the user to have an _intentionally mis-encoded_
font that assigns non-Latin glyphs to the windows-1252 code points.
(Note that if the site says , that
continues to be undisturbed:
https://searchfox.org/mozilla-central/rev/62a130ba0ac80f75175e4b65536290b52391f116/parser/html/nsHtml5StreamParser.cpp#1512
)

Chrome has detection for three windows-1252-misusing Devanagari font
encodings and nine Tamil ones. (Nine looks like a lot, but Python tool
in this space is documented to handle 25 Tamil legacy encodings!)
There is no indication that the Chrome developers found it necessary
to have these detections. Actively-maintained newspaper sites that,
according to old Bugzilla items, previously used these font hacks have
migrated to Unicode. Rather, it looks like Chrome inherited them from
Google search engine code. Still, this leaves the possibility that
there are sites that presently work (if the user has the appropriate
fonts installed) in Chrome thanks to this detection and in Firefox
thanks to Firefox mapping the .in TLD to windows-1252 and mapping .com
to windows-1252 in the English localizations as well as in the
localizations for the Brahmic-script languages of India.

By not enabling the new detector on .in at least for now avoids
disrupting sites that intentionally misuse windows-1252 without
declaring it if such sites are still used by users (at the expense of
out-of-locale usage of .in as a generic TLD; data disclosed by Google
as part of Chrome's detector suggest e.g. Japanese use of .in). To the
extent the phenomenon of relying on intentionally misencoded fonts
still exists but on .com, the new detector will likely disrupt it
(likely by guessing some Cyrillic encoding). However, I think it
doesn't make sense to let that possibility derail this whole
project/feature.

Although I believe this phenomenon to be mostly a Tamil in Tamil Nadu
thing rather than a general Tamil language thing, I disabled the
detector on .lk just in case to have more time to research the issue.

If reports of legacy Tamil sites breaking show up, please needinfo me
on Bugzilla.

I didn't disable the detector for .am, because Chrome doesn't appear
to have detections for Armenian intentional misuse of windows-1252.

If intl.charset.detector.ng.enabled is false, Japanese detection
behaves like previously, except that encoding inheritance from a
same-origin parent frame now takes precedence over the detector. (This
was a spec compliance bug that had previously gone unnoticed because
we hadn't run the full test suite with a detector enabled. It turns
out that tests both semi-intentionally and accidentally depend on
same-origin inheritance taking precedence as the spec says.)

In the interest of binary size, I removed the old Cyrillic detector at
the same time as landing the new one. If the new detector is disabled
by the old Cyrillic detector is enabled, the new detector runs in the
situations where the old Cyrillic detector would have run in a mode
that approximates the old Cyrillic detector. (This approximation can,
however, result in some non-Cyrillic outcomes that were impossible
with the old Cyrillic detector.)

> # web-platform-tests

I added tests as tentative WPTs.

-- 
Henri Sivonen
hsivo...@mozilla.com
___
dev-platform 

PSA: Dispatching background tasks just got easier!

[Kristen Wright]

Hello!
Now that Bug 1584568  just landed I wanted to
mention the new background thread pool for general purpose and blocking IO
runnables. Existing one-off threads, as well as new jobs that you may want
to run async in the background, can go to the new background thread pool
with NS_DispatchBackgroundTask(...)
.
If you've got something that cares about what order it runs in you would
want to use NS_CreateBackgroundTaskQueue

instead.

In the past, we've sent a lot of general I/O jobs to the stream transport
service. For a lot of cases, it's now possible to use the dedicated
background threads instead. To access the I/O threads when dispatching to
the pool or to a background task queue, use the NS_DISPATCH_EVENT_MAY_BLOCK

flag, to ensure that blocking I/O goes to its dedicated thread pool.

For a lot of cases, converting your existing async jobs or adding new ones
is pretty straightforward. Some examples of using background dispatch can
be found in Bug 1594858  for a basic background
task, Bug 1595242  for some background I/O, and Bug
1594814  for one that needs to use a background
task queue. Our tracking bug for this work is Bug 1595241
.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How best to do async functions and XPCOM?

[Boris Zbarsky]

On 12/10/19 3:31 PM, Kris Maglione wrote:

In what way is dom::Promise annoying to use from C++?


The one thing I know about that's pretty annoying is if you receive the 
promise from someone else and want to add reactions to it. 
PromiseNativeHandler kinda works, but then you get JS::Values and have 
to extract the things you care about from them manually, which is a bit 
of a pain.


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