MinGW Target on TaskCluster

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


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

Re: nsIAtom has been deCOMtaminated and is now called nsAtom

[Nicholas Nethercote]

On Mon, Oct 9, 2017 at 1:32 PM, Kyle Huey  wrote:

>
> You couldn't get to mozilla::Atom?
>

See https://bugzilla.mozilla.org/show_bug.cgi?id=1400460#c2.

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

Re: nsIAtom has been deCOMtaminated and is now called nsAtom

[Kyle Huey]

Awesome!

You couldn't get to mozilla::Atom?

- Kyle

On Oct 8, 2017 7:27 PM, "Nicholas Nethercote" 
wrote:

> Greetings,
>
> I have been deCOMtaminating nsIAtom over the past two months:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1392883.
>
> A big step that landed over a week ago was the devirtualization of nsIAtom,
> which means it is no longer a subclass of nsISupports:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1400459.
>
> And I just landed (on autoland) the final step of renaming nsIAtom as
> nsAtom. This is tracked at
> https://bugzilla.mozilla.org/show_bug.cgi?id=1400460.
>
> Apologies for any conflicts or problems caused in outstanding patches. For
> patches less than 1.5 weeks old (i.e. post-devirtualization) it's very
> likely that simply replacing all nsIAtom occurrences with nsAtom will
> suffice. For patches older than that here is a summary of changes that
> might be required.
>
> - nsIAtom --> nsAtom
>
> - nsCOMPtr --> RefPtr
>
> - nsCOMArray --> nsTArray
>   - Count() --> Length()
>   - ObjectAt() --> ElementAt()
>   - AppendObject() --> AppendElement()
>   - RemoveObjectAt() --> RemoveElementAt()
>
> - ns*Hashtable -->
>   ns*Hashtable
>
> - nsInterfaceHashtable --> nsRefPtrHashtable
>
>   # If the array contains atoms.
> - nsCOMPtr --> nsTArray
>   - nsArrayBase::Create() --> nsTArray()
>   - GetLength() --> Length()
>   - do_QueryElementAt() --> operator[]
>
> Nick
> ___
> 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

nsIAtom has been deCOMtaminated and is now called nsAtom

[Nicholas Nethercote]

Greetings,

I have been deCOMtaminating nsIAtom over the past two months:
https://bugzilla.mozilla.org/show_bug.cgi?id=1392883.

A big step that landed over a week ago was the devirtualization of nsIAtom,
which means it is no longer a subclass of nsISupports:
https://bugzilla.mozilla.org/show_bug.cgi?id=1400459.

And I just landed (on autoland) the final step of renaming nsIAtom as
nsAtom. This is tracked at
https://bugzilla.mozilla.org/show_bug.cgi?id=1400460.

Apologies for any conflicts or problems caused in outstanding patches. For
patches less than 1.5 weeks old (i.e. post-devirtualization) it's very
likely that simply replacing all nsIAtom occurrences with nsAtom will
suffice. For patches older than that here is a summary of changes that
might be required.

- nsIAtom --> nsAtom

- nsCOMPtr --> RefPtr

- nsCOMArray --> nsTArray
  - Count() --> Length()
  - ObjectAt() --> ElementAt()
  - AppendObject() --> AppendElement()
  - RemoveObjectAt() --> RemoveElementAt()

- ns*Hashtable -->
  ns*Hashtable

- nsInterfaceHashtable --> nsRefPtrHashtable

  # If the array contains atoms.
- nsCOMPtr --> nsTArray
  - nsArrayBase::Create() --> nsTArray()
  - GetLength() --> Length()
  - do_QueryElementAt() --> operator[]

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

Re: Intent to ship: Retained Display Lists

[Boris Zbarsky]

On 10/8/17 8:22 PM, Matt Woodrow wrote:
We're planning to land into mozilla-central in the next week or two, and 
then enable it by default for Nightly within a week or two of that.


This is awesome news.  Big thanks to everyone who worked on this!

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

Intent to ship: Retained Display Lists

[Matt Woodrow]

Hello all,


We're planning on landing the code for retaining display lists in 58, 
behind the pref layout.display.list.retain.



This is a rather large reworking of how we paint, and was designed to 
address telemetry results [1] showing that display list building was 
consuming considerable amounts of our total paint time (around 40% on 
average). The new code retains the display list, and attempts to merge 
in partial updates rather than rebuilding the list from scratch each 
paint (as we currently do). We're tracking this in bug 1352499, which 
includes a link to all the planning and telemetry details.



Miko Mynttinen has been working on gathering some performance data [2], 
which is showing some really big wins, including a 77% reduction in 
display list building time on YouTube when we manage to do a partial 
update. These are just preliminary results, and we have a lot of 
remaining plans to build off this architecture and get further wins. We 
also have a few talos regressions due to the increased bookkeeping 
required for this, though we're working on minimizing these as much as 
possible. This is due to most Talos tests measuring first paint 
performance, and this change optimizes the second (and later) paints, 
which we believe to be more useful for perceived performance.



We're planning to land into mozilla-central in the next week or two, and 
then enable it by default for Nightly within a week or two of that. I'll 
send a follow-up email once we do land so that anyone interested can 
flip the pref and give us early feedback. Our current plan is to ride 
the trains for 58, possibly with a partial rollout for beta, and we'll 
make a decision on that closer to the merge date.



We do have significant testing for this via reftests, though it has been 
identified that we have a relative lack of testing for dynamic changes. 
Jonathan Watt is working on a fuzzer addition to the reftest harness 
that will generate random mutations which will increase our confidence 
in correctness and stability here.




Thanks to everyone who has helped work on this, including: Miko 
Mynttinen, Timothy Nikkel, Markus Stange, Ethan Lin and Jonathan Watt.




- Matt



[1] 
https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0_date=2017-10-05=r!dl%252Cflb!dl!flb_channel_version=beta%252F57=CONTENT_LARGE_PAINT_PHASE_WEIGHT_channel_version=null=Windows_NT=*=Firefox=1_keys=submissions_date=2017-09-25=0=1_submission_date=0 



[2]http://miko.lol/shared/mozilla/retained-dl-measurements-2017-10-05.pdf

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

Re: Changes to tab min-width

[testo . moz]

If you introduced the setting, I think it would increase it up to 150px to be 
able to see more tab title.  Particularly when I have a lot of tabs from the 
same site open, it could help.

At this moment I have 45 tabs open in Firefox, and 25 in Firefox Developer 
edition.  Tabs start scrolling for me at about 15.  I do like to just use the 
touch pad on my macbook to side swipe to move between the tabs.  If I have to 
use the < > buttons to move between the tabs that becomes painful as I can 
never get it to stop where I want.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[vmarty89]

In my opinion, the important thing is that this is not about disabling 
scrolling behaviour altogether. This will not affect users with <10 tabs, it 
will possibly help Chrome users with 10-20 tabs, and it will destroy both use 
cases for users with >20 tabs because the tabs will be unreadable AND still 
scroll out of view.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[yoasif]

On Tuesday, October 3, 2017 at 4:36:40 PM UTC-4, Jeff Griffiths wrote:
 
> 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?

1. Prefer old behavior, but can understand the desire for the new behavior as 
well. 

2. I'm trying to keep an open mind and I'm mostly okay with 80px as a balance. 
50 or less would likely look better if we didn't try to show text at all and 
instead showed just a favicon or a close button like Chrome does.  

It feels a bit like you are trying to ape the look of Chrome without trying to 
observe what makes it work -- even though in my mind, it still doesn't work all 
that well. 

As a long time Firefox user, if I want to find a tab, I just use the awesomebar 
% token to find the tab I am interested in, if it's not shown on screen. If it 
is shown on screen, I'm more likely to ctrl+tab/ctrl+shift+tab over to it, but 
the text is often helpful here -- multiple tabs with the same favicon doesn't 
tell me how many tabs I need to pass over to get to where I want to be, unless 
I look at the tab contents, which is the poor behavior that Chrome forces. 

One thing I noticed about Chrome (I opened it to play with their tab behavior) 
is that once the tabs get very pointy, *they overflow*, and in a way that 
doesn't even let users drag the the overflowed tabs to a new window, or to 
close it without using keyboard shortcuts. They overflow into a nether where 
they aren't visible *at all*.

At least Firefox prevents that behavior. 

> 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.

That may be the case, but I currently have 49 tabs open in the tab I am 
composing this message in, and I routinely walk by people at work who have 20 
tabs or so open. 

> Moving forward there are a few different options:

I think that this is being done with very short notice (why are we talking 
about doing this in Firefox 57 - if this was important, shouldn't it have been 
discussed or under planning for a few weeks or months at least?) - or is a way 
to make a change on a whim that you believe will make Chrome users comfortable 
without having to deal with a lot of review? I'd prefer to not look at this 
cynically, but I've seen Mozilla's developers move -- it's generally 
deliberately, and always trying to make the right call. This feels a lot more 
like guesswork. 

Either way, I think this should be a *user facing* preference - the customize 
UI makes the most sense to me, but about:preferences would work too. A live 
slider would probably work great, but a dropdown like exists for density in 
customize should also work. 

I strongly don't believe that this should only be accessible via about:config. 

I also don't think that existing Firefox users should be auto-migrated to this 
preference. If anything, it should only be for new installers where there 
Chrome is already installed (new installers where only Safari/Edge are 
installed show no clear "preference" for the Chrome behavior).

Why also not set up some experiments here targeting high tab users?
 
> 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.

This feels more like a design problem that should probably be solved more 
immediately if you want to push 50px tabs out (which who knows, may be ideal 
for switchers). 

Some suggestions:

1. Don't try to show any text, show favicons/speaker icon when tab get too small
2. Play with the look of the tab bar -- the new default theme looks ugly when I 
have many tabs open at 50px. I'm sure not constraining design to the new Photon 
UI and rethinking some of the look would produce a better result (this is why I 
feel that this is being done on a whim, I don't think design would have let 
this out as it is with 50px; it is *ugly*). Amusingly enough Chrome looks more 
like Australis currently.
3. Pinned tabs behavior feels fine to me. 
4. Don't get rid of overflow. Chrome's behavior is broken.

Note: I prefer the existing behavior, but I hope the above demonstrates that 
this requires more design thinking than doing this on a whim. 

> cheers, Jeff
> 
> [1] https://hg.mozilla.org/integration/autoland/rev/a75e0386aad8

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

Re: Changes to tab min-width

[Randell Jesup]

>> I find (perhaps because I'm a mozilla user, and a tab-hoarder) that
>> Chrome's UI is DREADFUL for anyone with lots of tabs - and probably
>> intentionally to push users into closing them, since large numbers of
>> tabs simply doesn't work as well in Chrome as in Firefox.  So mimicing
>> their behavior is NOT a good idea, IMHO.
>
>I'm one of the people (a minority in this thread, it appears) who prefers
>Chrome's behavior and who'd like a skinny-tab option in Firefox, though not
>necessarily the default option. I use all the major browsers, typically
>with a dozen or more tabs open in the browser I'm using for my primary work
>at any given time. I vastly prefer Chrome's tab behavior for several
>reasons and rely on it as my primary browser in part because of it.

Sounds like a good option for an extension.

>I believe the complaint of "XYZ pixels is too narrow because it hides
>necessary information in the tab" misses another point. For me, having tabs
>vanish off one side or the other of the tab strip is a worse omission of
>important information.

I have enough tabs that there's No Way they can even be visible as close
boxes (and it's useless to me when it gets down to favicon).  And I get
that you have a different set of behaviors/preferences.

An un-discoverable feature of the Awesome Bar is
"%url-fragment/title-fragment".  It will show you completions
from the list of open tabs only.  This (and using scroll-wheels to spin
quickly through a overflowing tab bar) make large numbers of tabs
feasible without going the huge number of windows route.

I think we could do skinnier tabs if we retained the ability to see what
they are (not just favicon) easily.  The more I think of it, the more I
like the dock-like expand-what's-near-the-mouse idea - I wonder how easy
it is?

>I have typically navigate my 20 or 30 or 40 tabs mostly by keyboard,
>cycling one way or the other across the tab strip, and for me the spatial
>arrangement is very important (as is tab-switching speed).

I find spatial organization is also quite useful, but I orient myself to
it visually.  I never use the keyboard nav - don't even know what the
bindings are. :-)

>There is an argument to be made for making life easier for people moving to
>Firefox from Chrome, which clearly is an ambition in the current Firefox 57
>Quantum push. I don't have any data about how widespread my preferences are
>or how much of a barrier it is adjusting to Firefox's disappearing tabs,
>but this heavy Chrome user prefers Chrome's approach.
>
>I'm not trying to argue that my preferences are universal. But I expect
>Google made its choices pretty carefully and not as a way to punish people
>for using too many tabs. I use lots more tabs than the average user, but I
>expect the general trend is drifting toward more and more tabs, so graceful
>handling of overflow will become important for a larger fraction of people
>as time goes on.

Having a option for tab-handling might be good; it's a primary way users
interact with the browser -- and *no* single way is the Right Way for
all users.  Extensions can help here, modulo most users don't look for
them.  You could also offer that (extension or option) when they import
profile data from Chrome, or put a link in Prefs to a Chrome-like tab
WebExtension (Prefs *could* have links to relevant Extensions).

-- 
Randell Jesup, Mozilla Corp
remove "news" for personal email
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[stephen . shankland]

> I don't know about you, but a common case for me is go-to-news-site,
> open-N-articles-in-tabs, read-articles (maybe ;-) ).  Probably learned
> that in the days of less bandwidth; stuff can pull down in the
> background.  Saves a lot of go-back,
> wait-for-page-to-load/render/scroll/etc.
> 
> For that usage, I need at least a word or so of the title - N tabs
> together with the same favicon.  Current width mostly works for this.
> 
> I find (perhaps because I'm a mozilla user, and a tab-hoarder) that
> Chrome's UI is DREADFUL for anyone with lots of tabs - and probably
> intentionally to push users into closing them, since large numbers of
> tabs simply doesn't work as well in Chrome as in Firefox.  So mimicing
> their behavior is NOT a good idea, IMHO.

I'm one of the people (a minority in this thread, it appears) who prefers 
Chrome's behavior and who'd like a skinny-tab option in Firefox, though not 
necessarily the default option. I use all the major browsers, typically with a 
dozen or more tabs open in the browser I'm using for my primary work at any 
given time. I vastly prefer Chrome's tab behavior for several reasons and rely 
on it as my primary browser in part because of it.

I believe the complaint of "XYZ pixels is too narrow because it hides necessary 
information in the tab" misses another point. For me, having tabs vanish off 
one side or the other of the tab strip is a worse omission of important 
information.

I have typically navigate my 20 or 30 or 40 tabs mostly by keyboard, cycling 
one way or the other across the tab strip, and for me the spatial arrangement 
is very important (as is tab-switching speed). I keep a mental map where 
everything is, and the tab strip mirrors it. I have different patches of a few 
nearby tabs for related tasks, for example. When some or most tabs are hidden, 
I find I get "lost." One visible tab strip helps me remember what I have going 
on when I lose track during multiasking moments. In Firefox, I have to 
compensate by opening new browser windows (harder than in Chrome since I can't 
select a group of them and tear them away to a new window) to manually 
partition my work into different clusters of tabs.

Chrome gracefully degrades the amount of information visible on each tab in a 
way I find useful. I often have lots of tabs with the same favicon visible 
(Google Docs, news articles from one website, etc) and though it would be nice 
to see full tabs I find the favicon is enough for me to keep my bearings. Most 
of the time, though, I have many different websites open and a glance at the 
favicons is all I need to know what's up.

The audio indicator is indeed a very useful part of the tab UI. In Chrome, it's 
the last thing visible as tabs get narrower, obscuring even the favicon. The 
close box disappears as tabs get narrower, but it's still visible on the active 
tab. When tabs are so narrow that only one item is visible, the close box is 
that single thing (overriding the audio indicator). Google clearly thought 
about this behavior carefully, and I vastly prefer it and often use Chrome for 
my primary work browser purely because I dislike Firefox's disappearing tabs so 
much.

There is an argument to be made for making life easier for people moving to 
Firefox from Chrome, which clearly is an ambition in the current Firefox 57 
Quantum push. I don't have any data about how widespread my preferences are or 
how much of a barrier it is adjusting to Firefox's disappearing tabs, but this 
heavy Chrome user prefers Chrome's approach.

I'm not trying to argue that my preferences are universal. But I expect Google 
made its choices pretty carefully and not as a way to punish people for using 
too many tabs. I use lots more tabs than the average user, but I expect the 
general trend is drifting toward more and more tabs, so graceful handling of 
overflow will become important for a larger fraction of people as time goes on.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to tab min-width

[jan . skurski]

Hi, just a (power?) user input here, my subjective POV.

In fact I was a little frightened when that min-width changed in Nightly. I 
liked very much the old behaviour, to see only a fraction of opened tabs (I'm 
nearly always in the overflow territory anyway), disliked Chrome for that 
"compression" of tabs. I don't see anything wrong with scrolling - if I want to 
see all tabs, I have a drop-down option for it, keyboard shortcuts and all.

As I am always at the overflow limit, I am:
1) Not seeing much text at the 50px (75px is not much better for me)
2) simply overwhelmed by that "compression" of tabs - it's highly subjective, 
but very noticable for me. (it's like a psychological discomfort, hard to 
describe it properly)

All in all, I feel comfortable with 100px, even 90px feels a little too low for 
me - not much text shown.

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