Re: Changes to tab min-width

[Miha]

When I first saw tabs shrink in Firefox 58a I thought it's a nasty bug and I 
started reporting it to Bugzilla. I found this thread and I'm glad this 
negative behaviour is open to discussion.

As soon as I read it's possible I have used 'browser.tabs.tabMinWidth' to 'fix' 
the change. I have changed the numbers a bit and 95 plays nice with me. This is 
how I see this:

1. I use many tabs (200+). If all tabs have the width of 50, then there's only 
the favicon shown. Which, as already noted by others, will be the same for many 
tabs. Not to mention that some sites don't have a favicon, so they will all 
look the same. Not to mention that this way all tabs look similar or almost the 
same as pinned tabs.

2. Before FF 57 I was using "Faviconize tab" add-on (it doesn't work with FF57 
any more because of WebExtensions). It enables to select the tab and make it 
shrink to favicon size only (and also expand). That addon was super useful and 
I would welcome this kind of default behaviour. That way the user can choose 
how large the tabs should be. Furthermore, if they want some tabs large and 
some small, they can have them.

3. I'm reading here that some people find tab scrolling to the side 
disorienting. I disagree. It's much more useful than a new row (or rows!) of 
tabs because that one takes screen estate.

4. I'm also reading here that other people find weird that the drop-down tab 
arrow is not visible with a smaller number of tabs and shows up only after some 
10+ tabs are open. I'm one of those, too. Always visible would be preferable.

5. I also agree that tab changes should be based on an experiment focused on 
heavy tabs users and not just on a gut feeling.

6. Since we're debating long-term changes to tab behaviour I would use this 
place to suggest nested tabs or a tree of tabs in the tab row. Right now, one 
tab means one web site. I'm proposing that one tab could mean a drop down menu 
of user-grouped tabs (websites). This way there would be more space available 
for tabs and users could have some tab grouping. There are some addons, but 
they all do this in the sidebar which i use for different purpose.

7. Also, speaking long-term, I welcome Containter tabs. I was sceptic at first 
but after I tried them they're very useful and easy to use. Also, visually 
distinguishable from the rest of tabs. I usually used Chrome before for having 
the second set of tabs open with a different account, but since my computer 
crashed a month ago, I haven't found a need even to install it. I just use a 
few Container tabs.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: MinGW Target on TaskCluster

[Tom Ritter]

On Mon, Oct 9, 2017 at 10:31 AM, Philipp Wagner 
wrote:

> Am 09.10.2017 um 07:31 schrieb Tom Ritter:
> > As part of our work with Tor, we’ve been working on getting a MinGW-based
> > build of Windows into TaskCluster.
>
> A maybe too obvious question from the side lines: Why is the Tor browser
> cross-compiled and not using MSVC?
>
>
Building on Linux allows Tor Browser (including its entire toolchain and
dependencies) to be built deterministically and thus reproducibly using an
entirely open source toolchain. (There are a few small exceptions but
they're quite small.)

Reproducible builds significantly reduce the trust inherent in an
organization's build infrastructure and when recreated independently ensure
that nothing unexpected was inserted into the final executable. Having the
entire toolchain open source ensures that anyone who wants to inspect the
code or reason about its behavior can do so. (And as I've learned in the
past year Tor actually has a good amount of anonymous contributors reading
the source code of its toolchain and reporting things.)

You can read more about the philosophy behind this movement at
https://blog.torproject.org/deterministic-builds-part-one-cyberwar-and-global-compromise
https://reproducible-builds.org/
CCleaner is a good example of attackers backdooring compiled software.

The next step, past reproducible builds, is Binary Transparency, which
ensures that before an update is applied, it is publicly known, so
attackers cannot surreptitiously subvert the update mechanism.  Tor is
exploring some avenues there. FLAME is a good example of attacking the
update mechanism.

I would describe Mozilla as 'curious' about reproducible builds (see
https://bugzilla.mozilla.org/show_bug.cgi?id=885777); but we are actively
working on Binary Transparency (see
https://bugzilla.mozilla.org/show_bug.cgi?id=1341395).

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

Re: MinGW Target on TaskCluster

[Philipp Wagner]

Am 09.10.2017 um 07:31 schrieb Tom Ritter:
> As part of our work with Tor, we’ve been working on getting a MinGW-based
> build of Windows into TaskCluster. 

A maybe too obvious question from the side lines: Why is the Tor browser
cross-compiled and not using MSVC?

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

Re: Intent to Enable: Automated Static Analysis feedback in MozReview

[Jan Keromnes]

Thanks Patrick.

C/C++ was our top priority because code defects are very costly, but we'd
love to make our static analysis bot support additional languages, so we're
looking into integrating with mozlint [0] (the  `./mach lint` wrapper
around eslint, flake8 and wptlint), and I think we should also use clippy
to lint Rust code.

[0] https://firefox-source-docs.mozilla.org/tools/lint/index.html

On Mon, Oct 9, 2017 at 3:43 PM, Patrick Brosset 
wrote:

> This sounds awesome Jan.
> Are there plans to have something similar for JS code linting (with
> ESLint)?
>
> On Wed, Oct 4, 2017 at 7:14 PM, Ehsan Akhgari 
> wrote:
>
>> On 10/04/2017 03:17 AM, Jan Keromnes wrote:
>>
>>> TL;DR -- We wrote a static analysis bot for MozReview ("clangbot") and
>>> it's
>>> about to complain about any patches that would introduce new C/C++ code
>>> defects to Firefox.
>>>
>> This is fantastic to see, thank you for making it happen!
>>
>> ___
>> 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: C++ function that the optimizer won't eliminate

[David Major]

> On Fri, Oct 6, 2017 at 5:41 PM, David Major  wrote:
> > I bet Google Benchmark will have what you want.
> >
> > As a first guess, maybe this?
> > https://github.com/google/benchmark/blob/master/include/
> benchmark/benchmark.h#L297
>
> Thank you. I guess it's the best to import that into the tree even
> though it seems to only consume values without returning a value.
> (I've been under the impression that it would be prudent to taint
> benchmark inputs as untrackable by the optimizer also.)
>
> I'm a bit surprised that the MSVC code path relies on an empty
> out-of-line function and not on inline asm.
>
>
MSVC doesn't allow inline assembly in 64-bit code.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Enable: Automated Static Analysis feedback in MozReview

[Patrick Brosset]

This sounds awesome Jan.
Are there plans to have something similar for JS code linting (with ESLint)?

On Wed, Oct 4, 2017 at 7:14 PM, Ehsan Akhgari 
wrote:

> On 10/04/2017 03:17 AM, Jan Keromnes wrote:
>
>> TL;DR -- We wrote a static analysis bot for MozReview ("clangbot") and
>> it's
>> about to complain about any patches that would introduce new C/C++ code
>> defects to Firefox.
>>
> This is fantastic to see, thank you for making it happen!
>
> ___
> 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: C++ function that the optimizer won't eliminate

[Henri Sivonen]

On Fri, Oct 6, 2017 at 4:16 PM, Gabriele Svelto  wrote:
> IIUC what you are looking for is the '+' constraint which implies the
> parameter is both read and written in the asm statement, e.g.:

Thanks.

On Fri, Oct 6, 2017 at 4:01 PM, Nathan Froyd  wrote:
> Can you provide a slightly larger example testcase (links to
> godbolt.org would be excellent) that actually uses this, so we can see
> what the compiler is doing?

https://godbolt.org/g/p4PQYT is the kind of thing that made me think
the black_box function was wrong.

Combining it with some action does seem to work in the sense that
there are 16 additions instead of one addition of 16:
https://godbolt.org/g/iTBXYW vs. https://godbolt.org/g/FkogJM

Adding volatile changes the output even when there's no action in the
loop other that the pointing going through the black box:
https://godbolt.org/g/35xcCL

> I think it's customary to make these sorts of asms `volatile asm` to
> tell the compiler to not touch it.  I don't know how to write one for
> MSVC, but I think a small variant of the above should work for GCC.

I omitted volatile, because the GCC manual said it has no effect on
basic asm. However, it turns out it still has an effect on extended
asm, which is what this is. Oops.

On Fri, Oct 6, 2017 at 5:41 PM, David Major  wrote:
> I bet Google Benchmark will have what you want.
>
> As a first guess, maybe this?
> https://github.com/google/benchmark/blob/master/include/benchmark/benchmark.h#L297

Thank you. I guess it's the best to import that into the tree even
though it seems to only consume values without returning a value.
(I've been under the impression that it would be prudent to taint
benchmark inputs as untrackable by the optimizer also.)

I'm a bit surprised that the MSVC code path relies on an empty
out-of-line function and not on inline asm.

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: MinGW Target on TaskCluster

[Ted Mielczarek]

On Mon, Oct 9, 2017, at 01:31 AM, Tom Ritter wrote:
> As part of our work with Tor, we’ve been working on getting a MinGW-based
> build of Windows into TaskCluster. Tor is currently using ESR releases,
> and
> every ESR they have to go through a large amount of work to get the build
> working under MinGW again; by continually building (and testing) that
> build
> we’ll be able to cut weeks to months of effort for them each ESR release.
> (Not breaking the MinGW build is also a necessity if they were ever to
> move
> off ESRs.)

Great work, Tom! I know this was a long slog, but keeping this build
working is going to lift a massive burden from the Tor Browser team.
Thanks for taking on this project and driving it to completion!

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

Re: MinGW Target on TaskCluster

[Georg Koppen]

Hi!

Tom Ritter:
> As part of our work with Tor, we’ve been working on getting a MinGW-based
> build of Windows into TaskCluster. Tor is currently using ESR releases, and
> every ESR they have to go through a large amount of work to get the build
> working under MinGW again; by continually building (and testing) that build
> we’ll be able to cut weeks to months of effort for them each ESR release.
> (Not breaking the MinGW build is also a necessity if they were ever to move
> off ESRs.)
> 
> Unlike our normal Windows builds with msvc or clang-cl, this is a
> cross-compile on Linux for Windows, as well as the first time in a long
> time we’ve built for Windows with gcc. Building with gcc for Windows has
> exposed a number of new warnings
>  to clean up, as well
> as some C++ spec incompatibilities that MSVC (and clang-cl) accept. All of
> the breaks have been resolved; and a lot of the warnings and similar are
> either resolved or in-progress.
> 
> Effective this weekend, MinGW is on Treeherder, with the single build
> target win32-mingw32 (debug). Its toolchain builds are under TMW (with a
> few under TL because they are generic Linux packages.)
> 
> The one-click loaner system works for MinGW, and we’re going to allow this
> to bake at Tier 2 for a while. Your help in keeping the build green is
> greatly appreciated, and if you hit a MinGW bug you can’t decipher, I’ll be
> happy to help, just send me an email or a needinfo. Some of the most common
> things that cause errors for MinGW:
> 
> 
>  - #include  instead of #include  and similar
> 
>  - _uuidof() instead of IID_* ref
> 
> 
>  - Casting nullptr to bool or int
> 
>  - Using the (in)correct assembly code
> 
>  - Breaking --disable-webrtc, --disable-sandbox, or --disable-accessibility
> 
>  - MinGW lagging behind on defining new constants Microsoft has defined
> 
> There are a few things left outstanding
> 
> for the MinGW build, including webrtc
> , stylo
>  (which may be the
> most difficult in this list), the sandbox
> ,
> --enable-accessibility
> , cleaning
> up warnings , and 
> running
> tests . In the
> future, there is hope (by me at least) to throw all of this work away.
> Compiling on Linux for Windows with clang (or clang-cl) would probably be a
> significant improvement for Tor’s builds, and would enable them to take
> advantage of CFI and SEH, as well as simplifying the number of platforms
> Mozilla supports. Chrome has been pushing towards this
> , so we’re
> keeping an eye on their progress.
> 
> Finally, I want to thank everyone who brought this long process to this
> point: everyone who wrote patches, explained things (sometimes over and
> over again), and reviewed. That’s including but not limited to: boklm,
> dmajor, froydnj, glandium, georg, jacek, jrmuizel, and ted; plus the dozen
> or so more people who have reviewed my patches all over the codebase.

That's great news, Tom! Thanks for working on this project and all its
numerous child bugs, greatly appreciated. I know from experience how
time-consuming and tedious this is.

To stress a point you made in your email above: your efforts and those
of other Mozilla engineers that helped with this project does indeed
save us weeks of work when preparing major Tor Browser releases based on
a new ESR. We can now use this valuable time to fix more privacy issues
faster which benefits both Tor Browser and Firefox users alike because
we upstream those patches as we think not only Tor users should benefit
from them.

As to your future plans, yes, we are happy if we can help with the
effort to move away from using GCC for Windows cross-builds and move to
clang instead. That's not only due to the SEH and CFI support you
mentioned. Rather, it would allow us to get rid of annoying GCC bugs,
like https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64384, as well and
would significantly simpify our cross-compile setups we need to maintain.

Thanks,
Georg



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[Firefox Desktop] Issues found: October 2nd to October 6th

[Cornel Ionce]

Hi everyone,

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


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
1406333 
The history and bookmarks expand/collapse buttons are heavy responsive
Firefox
Bookmarks & History
NO  NOBODY
1406401 
	The separators from Bookmarks Toolbar cannot be moved anymore with the 
mouse

Firefox
Toolbars and Customization
	YES 
 
	Sam Foster 


*
NIGHTLY CHANNEL**
*none

*ESR CHANNEL*
none


Regards,
Cornel (:cornel_ionce)
Desktop Release QA
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform