Re: Any plans to move the bug re. low cipher strength in Firefox' master password forward one day?

[Justin Dolske]

Yes, we're looking at it, but don't have a detailed plan or schedule to
share yet.

Justin

On Wed, Oct 3, 2018 at 10:40 AM Jörg Knobloch  wrote:

> Hi all,
>
> an unrelated discussion made me aware that the master password cipher
> strength bug[1] is still open. Any plans to tackle that?
>
> Other software uses strong AES algorithms for their "password
> collections". Would it be hard to follow?
>
> Jörg.
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=524403
>
> Plenty of bad press here:
>
> https://nakedsecurity.sophos.com/2018/03/20/nine-years-on-firefoxs-master-password-is-still-insecure/
>
> https://fossbytes.com/firefox-master-password-weak-encryption-brute-force-one-minute/
>
>
> ___
> 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: WebRender on in Firefox Nightly for Windows 10 Nvidia

[Justin Dolske]

\o/ Congrats on this major milestone! Exciting times for Firefox ahead! :D

Justin

On Wed, Sep 12, 2018 at 1:38 PM, Jean-Yves Avenard 
wrote:

> What an achievement…
>
> Congrats to you and the team….
>
> JY
>
> > On 12 Sep 2018, at 10:07 pm, Jeff Muizelaar 
> wrote:
> >
> > In bug 1490742 I have enabled WebRender in Nightly on non-laptop
> > Windows 10 Nvidia (~17% of our Nightly audience). This is a rewrite of
> > much the graphics backend in Firefox. We expect some edge-case
> > regressions, but generally nothing serious. We have quite a few staff
> > and volunteers who have been using WebRender for months without major
> > issues.
> >
> > If you're on this hardware and you see a problem please file a bug.
> > You can check if you're using WebRender by looking at the Compositing
> > section of about:support. Further, WebRender should be generally
> > usable on all platforms other than Android right now so if you want to
> > be keen you can try it out now with the gfx.webrender.all pref.
> >
> > -Jeff
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
>
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Major preference service architecture changes inbound

[Justin Dolske]

I know we've had code that, instead of reading a pref directly, checks the
pref once in an init() and uses pref observers to watch for any changes to
it. (i.e., basically mirrors the pref into some module-local variable, at
which point you can roll your own locking or whatever to make it
threadsafe). Is that a pattern that would work here, if people really want
OMT access but we're not ready to bake support for that into the pref
service? [Perhaps with some simple helper glue / boilerplate to make it
easier.]

Justin

On Thu, Jul 19, 2018 at 2:19 PM, Kris Maglione 
wrote:

> On Tue, Jul 17, 2018 at 03:49:41PM -0700, Jeff Gilbert wrote:
>
>> We should totally be able to afford the very low cost of a
>> rarely-contended lock. What's going on that causes uncached pref reads
>> to show up so hot in profiles? Do we have a list of problematic pref
>> keys?
>>
>
> So, at the moment, we read about 10,000 preferences at startup in debug
> builds. That number is probably slightly lower in non-debug builds, bug we
> don't collect stats there. We're working on reducing that number (which is
> why we collect statistics in the first place), but for now, it's still
> quite high.
>
>
> As for the cost of locks... On my machine, in a tight loop, the cost of a
> entering and exiting MutexAutoLock is about 37ns. This is pretty close to
> ideal circumstances, on a single core of a very fast CPU, with very fast
> RAM, everything cached, and no contention. If we could extrapolate that to
> normal usage, it would be about a third of a ms of additional overhead for
> startup. I've fought hard enough for 1ms startup time improvements, but
> *shrug*, if it were that simple, it might be acceptable.
>
> But I have no reason to think the lock would be rarely contended. We read
> preferences *a lot*, and if we allowed access from background threads, I
> have no doubt that we would start reading them a lot from background
> threads in addition to reading them a lot from the main thread.
>
> And that would mean, in addition to lock contention, cache contention and
> potentially even NUMA issues. Those last two apply to atomic var caches
> too, but at least they generally apply only to the specific var caches
> being accessed off-thread, rather than pref look-ups in general.
>
>
> Maybe we could get away with it at first, as long as off-thread usage
> remains low. But long term, I think it would be a performance foot-gun.
> And, paradoxically, the less foot-gunny it is, the less useful it probably
> is, too. If we're only using it off-thread in a few places, and don't have
> to worry about contention, why are we bothering with locking and off-thread
> access in the first place?
>
>
> On Tue, Jul 17, 2018 at 8:57 AM, Kris Maglione 
>> wrote:
>>
>>> On Tue, Jul 17, 2018 at 02:06:48PM +0100, Jonathan Kew wrote:
>>>

 On 13/07/2018 21:37, Kris Maglione wrote:

>
> tl;dr: A major change to the architecture preference service has just
> landed, so please be on the lookout for regressions.
>
> We've been working for the last few weeks on rearchitecting the
> preference service to work better in our current and future
> multi-process
> configurations, and those changes have just landed in bug 1471025.
>


 Looks like a great step forward!

 While we're thinking about the prefs service, is there any possibility
 we
 could enable off-main-thread access to preferences?

>>>
>>>
>>> I think the chances of that are pretty close to 0, but I'll defer to
>>> Nick.
>>>
>>> We definitely can't afford the locking overhead—preference look-ups
>>> already
>>> show up in profiles without it. And even the current limited exception
>>> that
>>> we grant Stylo while it has the main thread blocked causes problems (bug
>>> 1474789), since it makes it impossible to update statistics for those
>>> reads,
>>> or switch to Robin Hood hashing (which would make our hash tables much
>>> smaller and more efficient, but requires read operations to be able to
>>> move
>>> entries).
>>>
>>> I am aware that in simple cases, this can be achieved via the
 StaticPrefsList; by defining a VARCACHE_PREF there, I can read its value
 from other threads. But this doesn't help in my use case, where I need
 another thread to be able to query an extensible set of pref names that
 are
 not fully known at compile time.

 Currently, it looks like to do this, I'll have to iterate over the
 relevant prefs branch(es) ahead of time (on the main thread) and copy
 all
 the entries to some other place that is then available to my worker
 threads.
 For my use case, at least, the other threads only need read access;
 modifying prefs could still be limited to the main thread.

>>>
>>>
>>> That's probably your best option, yeah. Although I will say that those
>>> kinds
>>> of extensible preference sets aren't great for performance or memory
>>> usage,
>>> so switching 

Re: Yes=0, No=1

[Justin Dolske]

On Thu, Jul 12, 2018 at 1:28 PM, Jason Orendorff 
wrote:

>
> ...This is bad, right? Asking for a friend.
>
>
1

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

Re: New prefs parser has landed

[Justin Dolske]

Wow. Some of that is bizarre enough that I kinda want to go look at the old
parser code, but I value my sanity enough to not do so. Nice work.

Can I presume that things which now trigger parsing issues are escaped or
errored by the relevant prefs APIs? e.g. if a caller tries to set a pref
name or value with an embedded NULL?

Justin

On Thu, Feb 1, 2018 at 1:04 PM, Nicholas Nethercote 
wrote:

> Hi,
>
> I just landed https://bugzilla.mozilla.org/show_bug.cgi?id=1423840, which
> replaces the old prefs parser with a new one.
>
> The new parser is faster, safer, gives better and more accurate error
> messages, and is *much* easier to maintain.
>
> It is also slightly stricter; see the list at the bottom of this email for
> details (copied from the commit message). This increased strictness
> required fixes in a few places (in Firefox, Talos, and Thunderbird) where
> existing prefs files were doing bogus things that the old parser accepted,
> such as junk characters between prefs, and integer literal values that
> silently overflowed because they didn't fit in 32 bits.
>
> Please keep an eye out for any other problems that might arise from this
> change.
>
> Nick
>
>
> The new parser is slightly stricter than the old parser in a few ways.
>
> - Disconcertingly, the old parser allowed arbitrary junk between prefs
>   (including at the start and end of the prefs file) so long as that junk
>   didn't include any of the following chars: '/', '#', 'u', 's', 'p'. I.e.
>   lines like these:
>
> !foo@bar("prefname", true);
> ticky_pref("prefname", true);   // missing 's' at start
> User_pref("prefname", true);// should be 'u' at start
>
>   would all be treated the same as this:
>
> pref("prefname", true);
>
>   The new parser disallows such junk because it isn't necessary and seems
> like
>   an unintentional botch by the old parser.
>
> - The old parser allowed character 0x1a (SUB) between tokens and treated it
>   like '\n'.
>
>   The new parser does not allow this character. SUB was used to indicate
>   end-of-file (*not* end-of-line) in some old operating systems such as
> MS-DOS,
>   but this doesn't seem necessary today.
>
> - The old parser tolerated (with a warning) invalid escape sequences within
>   string literals -- such as "\q" (not a valid escape) and "\x1" and "\u12"
>   (both of which have insufficient hex digits) -- accepting them literally.
>
>   The new parser does not tolerate invalid escape sequences because it
> doesn't
>   seem necessary and would complicate things.
>
> - The old parser tolerated character 0x00 (NUL) within string literals;
> this is
>   dangerous because C++ code that manipulates string values with embedded
> NULs
>   will almost certainly consider those chars as end-of-string markers.
>
>   The new parser treats NUL chars as end-of-file, to avoid this danger and
>   because it facilitates a significant optimization (described within the
>   code).
>
> - The old parser allowed integer literals to overflow, silently wrapping
> them.
>
>   The new parser treats integer overflow as a parse error. This seems
> better,
>   and it caught existing overflows of places.database.lastMaintenance, in
>   testing/profiles/prefs_general.js (bug 1424030) and
>   testing/talos/talos/config.py (bug 1434813).
> ___
> 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: Change in the way e10s and multi are enabled on Nightly

[Justin Dolske]

On Wed, Oct 18, 2017 at 11:52 AM, Blake Kaplan  wrote:

>
> One more thing to point out: with the removal of e10srollout, I also
> removed the code that would disable e10s if we detected a
> non-multiprocessComptaible extension. We are entirely relying on the addon
> manager to refuse to install such extensions.
>
>
If someone on a pre-release channel enables legacy addons, will that still
refuse to load non-E10S compatible addons? (I hope so?)

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

Photon Engineering Newsletter #16

[Justin Dolske]

(via
https://dolske.wordpress.com/2017/09/22/photon-engineering-newsletter-16/)

Time to get your groove on! It’s Photon Newsletter #16
!

But first. Do you remember the 21st night of September
? As of today (September 21st)
Firefox 57 has passed its penultimate milestone by entering Beta. This is a
pretty big deal, as it means many millions of users on Beta will soon
experience all the awesomeness that’s packed into 57. Note that Beta builds
won’t actually go out until next week, on the 26th. But if you’re
running Developer
Edition , we’ve already
pushed out an early sneak-peek!

Did I mention that Developer Edition also got a snazzy new Firefox icon?
It’s nice. And blue.
[image: firefox-logo-developer-edition]

The past week has been very busy as we’ve been doing a major burst of bug
triage, just to make sure we’re not missing any already-reported critical
issues. The front-end teams went through nearly 600 untriaged bugs in just
a few days! The good news is that we didn’t find anything alarming, which
matches up with our general impression that 57 is shaping up to be a really
solid release.
Recent Changes
Menus/structure:

   - The Library panel now has a “Recent Highlights
   ” section, which
   shows recent bookmarks and history. There’s also a new Downloads subview.
   
   [image: library]
   - Re-landed the autohiding download button
   , this time with a
   pref to allow disabling the autohide behavior (currently shown when
   clicking on it in Customize Mode). We think the default behavior will work
   for most people – the Downloads button only appearing when there are
   Downloads in the current session, and the Downloads subview in the Library
   as the permanent location to access your list of downloads. But this pref
   allow you to keep the old Downloads button behavior. (This was backed out a
   few weeks ago, in part due to confusion from not yet having the Downloads
   subview.)
   [image: dlhide]
   - Added hover states
    to the page
   action items when in the urlbar, as well as for the bookmark star.
   
   - More  changes
    to the ordering
   of the page action items
    (hopefully we’re
   done tweaking this now!)
   - Contributor Maya Messinger made the hamburger menu’s Print item
    directly invoke
   the print dialog, instead of opening print preview mode first (on Windows
   and Linux; macOS already did this). Maya also tweaked the ordering of
   the library menu .
   Thanks for the patches!
   - Updated the panel animations
   , which now make
   subviews appear to “push” content aside, instead of sliding over it.
   - The overflow panel now has rounded corners on macOS
   
   [image: Screen Shot 2017-09-21 at 11.28.17 PM]
   - Made the overflow panel look nicer in customize mode
   .
   - Unified the styling of various panel footers
   , which had been
   slightly different.
   - Fixed an issue involving keyboard navigation and the search box
in the overflow
   panel , and an
   issue with alignment of the account header of the hamburger panel
   
   - Bugfix for an problem where the bookmarks panel appeared in the wrong
   place .
   - Fixed an issue that sometimes prevented removing flexible spaces
   
   - Fixed several 
   minor issues  with
   screenshots (recently landed in Nightly, but has been in the screenshots
   repo a while).
   - Fixed an issue where the hamburger menu closed prematurely
   .
   - Fixed a bug causing the the urlbar and search box to increase in size
   when typing 
   - Made the title bar and drag space checkboxes
    in Customize mode
   readable when using a dark theme.
   - Fixed the 

Photon Engineering Newsletter #15

[Justin Dolske]

I’m back from a vacation to see the eclipse ,
so it’s time for Newsletter #15
! (It’s taking me some time to
get caught up, so this update covers the last 2 or so weeks.)

As noted in my previous

update, Mike and Jared took over Newsletter duties while I was out. If you
somehow missed their excellent updates – Newsletter #13

and Newsletter #14
 –
please check them out. (Go ahead, I’ll wait.)

We’re getting very close to Firefox 57 entering Beta! Code merges to the
Beta on September 20th, and the first Beta release should come on the 26th.
The Photon project is targeting the 15th to be ready for Beta, just to make
sure there’s a bit of time to spare. We’ll be continuing to fix bugs and
improve polish during the Beta, but the type of fixes we make will begin to
scale back, as we focus on making sure 57 is a rock-solid release. This
means becoming increasingly risk-adverse – there will always be bugs (and
more releases to fix them in), so we very much want to avoid causing new
regressions shortly before 57 ships to everybody. Last-minute firedrills
are no fun for anyone. But we’re in really great shape right now – we’re
done with feature development, are already shifting to more minor fixes,
and there isn’t anything really scary waiting to be fixed.
Recent Changes

Menus/structure:

   - The order of the icons
    in the URL bar
   was updated.
   - When navigating Photon-style panels with the keyboard, the previously
   selected item 
   will remain hilighted when going back.
   - Library  and page
   action 
   integration for screenshots finally made it to Nightly.
   
   - The URL bar dropmarker will now disappear when typing
   .
   - Fixed some more
 ordering
   issues  in the
   page actions in the url bar.
   - Fixed an issue with send to device where the popup would stay open
   after sending a tab
   .
   - Made the page action buttons announce themselves correctly to
   screenreaders .
   - The bookmarks menu and the sidebar header menu look more Photon-y
   .
   - The “Restore Previous Session” item is now a toplevel item in the
   hamburger panel .
   It (and its toplevel menubar cousin) also gets hidden (instead of disabled)
   if you’ve set Firefox to automatically restore your session.

Animation:

   - The “burst” across the tab
    when the page
   load is complete has landed.
   [image: tabload]
   - Added a “Copy URL” and “Send to Device” popup
    so that there’s
   clearer feedback when performing these actions.
   [image: copyinfo]
   - Various fixes to animations of the library button
   , tab loading
   indicator in RTL
, pocket
   icon corruption .
   - Fixed various follow-ups with the burst animation
   , tab loading
   indicator , and
   and copy link confirmation
   .
   - Fixed the animation of panels  when they are anchored at the bottom
   .

Preferences:

   - Once last P1 bug 
   to feature complete!
   - Team to move to help out Onboarding once all P1 and important P3s are
   fixed.

Visual redesign:

   - (A couple of slow weeks due to multiple people being sick and/or on
   PTO)
   - Minor update to sidebar styling on Linux
   .
   - The URL bar icon has been changed from an ⓘ to an  when on
   about:newtab , to
   better indicate that it can be used as a search field too.
   - Superstar contributor Tim Nguyen landed a patch to update notification
   icons 

Photon Engineering Newsletter #12

[Justin Dolske]

(via
https://dolske.wordpress.com/2017/08/13/photon-engineering-newsletter-12/ )

Let’s get straight into update #1
2
!

Oh, hey, anyone notice any icon chances recently? Yeah, they’re pretty
wonderful. Or maybe I should say *fun*derful? Looking forward to where they
end up!

[image: about-logo@2x]

Speaking of looking forward, I’m going to be on vacation
 for the
next two weeks. But fear not! Jared  and
Mike  will be covering Photon updates, so
you’ll still be able to get your Photon phix.
Recent Changes

Menus/structure:

   - When users first open Firefox 57, we will now move items they added to
   the old hamburger panel into the new overflow panel
   
  - As part of this work, the photon structure pref was removed, and we
  made a start with removing some of the old code we were lugging around
  until now. This removed over 2500 lines of code!
   - Pocket was added to the  page action menu
   .
   - You can now removed pinned page actions from the URL bar via a context
   menu  on the icons
   (in addition to the menu items in the page action menu itself).
   - The favicon for customize mode
    now matches the
   icon used elsewhere.
   - We broke, and then fixed, the history button
   . Oops. Sorry
   about that!
   - Fixed a bunch 
   of styling  and
   behavior  issues.

Animation:

   - New panel animations
    have landed.
   - More of the new download animation
    has landed. When
   a download starts, and arrow zooms into the download icon, and when it
   finishes the download icon expands/pulses a couple times.
  - Also made the download progressbar fill in the opposite direction
   in RTL locales.
   - Made adjustments to the stop-reload animation to stop playing the
   animation if pages load fast
   , also not playing
   the animation while tabs are opening or closing
   .

Preferences:

   - Completed a general facelift of preferences
    (font & size &
   colors) to match Photon style. New icons
   , too.
   - Removed all colons
    from subdialog
   headers.
   - Nearing completion of the Photon preferences MVP work!

Visual redesign:

   - Updated the button positions
    in the navbar,
   and made them more customizable. (This was a contributor patch – thanks!)
   - Close buttons updated across the UI
    (also a
   contributor patch!)
   - The “Compact Light” and “Compact Dark” themes have been renamed to
   simply “Light” and “Dark”. (The UI density setting is already independent
   of the theme.)

Onboarding:

   - Added the opt-out auto-refresh checkbox into the stub installer
   . When it finds
   you’re (re)installing Firefox on top of an already-installed Firefox that’s
   2+ versions out of date, it will offer to perform a profile refresh. This
   helps avoid problems with people who once tried Firefox, but then stopped
   using it (sometimes due to problems caused by an add-on or setting).
   [image: reinstall]
   - Updated the UITour highlight style
    to the Photon
   style.
   - Added UITour support for the Page Action panel
   , so the
   Onboarding can later use it to introduce the Screenshot feature located
   there.
   - Addressed a couple of accessibility
    issues
   .

Performance:

   - The tab strip now uses CSS smooth-scroll
   , which avoids
   janky synchronous reflows while scrolling through tabs.
   - When closing a tab, the next tab is now selected faster
   .
   - Replaced various timers with idle 

Photon Engineering Newsletter #11

[Justin Dolske]

(via
https://dolske.wordpress.com/2017/08/04/photon-engineering-newsletter-11/ )

H*ck yeah, it’s time for another Photon newsletter! They now go to #11
!
It’s Hip To Be Square

So… Perhaps you noticed something ever so slightly different in yesterday’s
Nightly. Something less curvy, and more rectangular. Look closely, right
there at the tabs. That’s right. No more curvy tabs!

[image: austphoton]


Behold, rectangular tabs! This is one of the last few major Photon features
to be implemented.

[image: tabs]

We think most people will like 
the new tab shape. Some people won’t like
 them. That’s ok.
We’ve done a lot of user testing, and have seen a lot of positive feedback
on the Photon mockups since they first came out. And, of course, the
Firefox Compact Light/Dark née DevTools themes have had square tabs for a
long time. So while it’s a big change to a very prominent piece of UI, it’s
also a change that’s a bit familiar, and really helps to make Firefox look
clean and modern.

(There’s a little bit more change still to come with the tabs – we’re going
to make them a little bit taller by default. This is being handled as a
separate follow-up fix, because we discovered that this surprisingly breaks
some of our automated tests. So while we’re fixing the tests, we wanted to
get the bulk of this change landed.)

R.I.P., curvy tabs.

[image: tabeol] 

Oh, and you may have also noticed – we updated all the navigation toolbar
icons to the new Photon style. They’re lighter-weight than the old icons.
We had been holding off on landing this until the start of Nightly-57,
simply because it wasn’t worth the effort to add extra code to allow both
the old and new icon sets to co-exist (since Nightly-56 would need to
disable those icons when it became Beta-56). But now that Nightly is on the
57 train, which will be shipping Photon, we don’t need to worry about that.
Recent Changes

Menus/structure:

   - Page action items can now be added to (and removed from) the location
   bar !
   [image: pageactionprotoi]
   - The History view in the Library button has been updated
    to show Recently
   Closed Tabs, Recently Closed Windows, and a “Recent History” label.
   [image: Screen Shot 2017-08-04 at 1.05.52 AM]
   - The overflow panel now has a footer
    to access
   Customization Mode.
   - Various smaller issues got fixed:
  - The search bar now responds correctly to its keyboard shortcut
   when inside
  the overflow panel
  - The Share button and other ‘unusual’ buttons
   now work
  better in the overflow panel
  - Fixed a mistake in context menus for the new flexible spaces
  
  - Page action panel now hides when switching tabs
  
  - Fixed styling issues with the sync item
   in the
  hamburger panel when not signed in

Animation:

   - Spent a good chunk of time tracking down a really weird layout issue
    with OSX 10.9 and
   Photon.
   - Made the overflow arrows point to the left
    in RTL builds.
   - Fixed a problem 
   (by backing out the offending patch) where the hamburger menu and other
   arrow panels would fail to open with some Linux window managers.

Preferences:

   - The Performance section in Preferences was found to have confusing
   behavior  because
   of how the E10S rollout changes user defaults.
   - Improved the performance
    of loading the
   preferences page.
   - Preferences now consistently refers to “websites” instead of “sites”
   .
   - Made the search box float at the top of the page
    (and persist as
   you scroll).
   - Made the checkbox + label clickable area wider
   .
   - Section names were invisible
    in Windows 7
   high-contrast mode.
   - Fixed  a variety
   

Photon Engineering Newsletter #10

[Justin Dolske]

(via
https://dolske.wordpress.com/2017/08/01/photon-engineering-newsletter-10/ )

Woo yeah!  Time for Photon newsletter #10
!
Nightly-57 this week

Way back in newsletter #2
,
I talked about the Photon program schedule. Briefly, to save you a click:
Photon is shipping with Firefox 57, and to allow time for bugfixes,
quality, and polish we’ve been targeting August 7th as the date when we’ll
be done with “major work.” That gives us 6 weeks of Nightly-57 to do that
bugfixing (and another 6 weeks of Beta-57 for any further critical or
low-risk improvements).

I’m pleased to report that we’re still solidly on track. Most of the
big-ticket features for Photon have already landed, and the last few
(notably: rectangular tabs, pinning Page Action items to the URL bar) are
in good shape to land soon. That’s not to say Photon is “done” – just that
the biggest and riskiest work will largely be behind us, and upcoming work
will start to be more about finishing off rough edges.
Recent Changes

Menus/structure:

   - Added a history view
    to the Library
   button
   - New overflow panel styling
    landed. This
   makes the overflow panel look much better in both customize mode and when
   opened from the toolbar.
   - Patches landed in github to have a Screenshots entry in the Library
   . (This won’t be
   user-visible until the next Screenshots-to-mozilla-central uplift.)
   - Added a customize footer to the overflow panel
   .

Animation:

   - The Stop/Reload animation has been tweaked to run faster
   .
   - Animations have been fixed to be positioned correctly regardless of
   display font size. [1]
    [2]
   
   - The Save to Bookmarks animation
    has landed in
   Nightly. (Add the Library button to the toolbar for the full effect!)
   [image: star]
   [image: bookmark-animation]
   - The Save to Pocket animation
    has also landed
   (Again, you’ll want to ensure the Library button is in the toolbar to see
   all of the animation.)
   [image: pocket-animation]

Preferences:

   - Fixed Performance section regression
    around number of
   processes and uplifted it to Beta-55.
   - Started working on visual refresh but are holding off landing until
   after the uplift. This allows QA to finish verifying the changes (in
   Nightly) that will ship with Firefox 56, without these 57-only changes
   getting in the way.

Visual redesign:

   - Fix for disappearing minimize button on Win 10.
   - Made the tab title text’s color better match the system text color
   .
   - Increase the size
    of main menu
   items when accessed through touch.
   - The titlebar on macOS is now colored in customize mode too
   .
   - Tweaked toolbar button and the location / search bar styling
    on Linux.
   - New tab strip icons
    for the New Tab
   and List All Tabs buttons.

Onboarding:

   - The first uncompleted tour is now shown by default
    (instead of just
   the first tour).
   - Updated the stub installer tagline
    to “Built for
   people, not for profit.
   - Made the “Learn More” button not wrap
   .
   - The Sync tour will be automatically marked as completed
    when you sign in
   with a Firefox account.
   - When refreshing a profile, don’t migrate a user’s session
    (tabs) unless the
   refresh was invoked by the user. This allows the reset triggered by the
   stub installer (e.g. for users coming back to Firefox after a long absence)
   to have a fresh experience, instead of seeing old tabs from months ago.
   - Made the onboarding UI look better in high-contrast mode
   .

Performance:

   - Landed an epic set of patches
    to gain a ~4% win
   on ts_paint 

Photon Engineering Newsletter #9

[Justin Dolske]

(via
https://dolske.wordpress.com/2017/07/24/photon-engineering-newsletter-9/)

Well, here we go again with a big update for Newsletter #9
! [Since the last update, I
took a vacation and ever since have been getting caught up. So this update
is terribly overdue. Sorry about that!]
Animations

Animations for toolbar icons are finally landing! Yay! :kermithands:
The stop/reload and pin-to-overflow animations are in Nightly, and the
Pocket, bookmarks, and downloads icons are next. I’d like to talk a little
about the way these animations are implemented. The effect is simple, but
there’s a lot of work behind the scenes.

As is often the case in engineering, we had a number of requirements that
needed to be satisfied. The most important was performance – we’re making
Firefox 57 blazing fast, and it wouldn’t do to have animations hurting that
work. We worked closely with our Graphics and Platform teams to develop a
technique (more on that in a second) that was efficient, and specifically
could run entirely within the compositor process
.
This helps ensure the animation can smoothly run at 60fps without impacting
(or being impacted by) all the other stuff running in the browser. The
other big requirement was around UX. We wanted to minimize the platform
technical constraints for our visual designers, so that their ideas were
not bound by platform limitations. [For example, we had an old patch
 to convert the
page-loading
throbber

from an APNG  to a static image
animated with a CSS transform (rotation). That’s nice, but then you’re
limited to effects possible in pure CSS.] We also needed to use SVG in the
animation, since the rest of Firefox’s icons are SVG now. This gives the
best result when scaling to different display DPI settings, and allows us
to dynamically adjust the icon colors based on system style.

The technique we’re using for Photon is based around an SVG “filmstrip” –
each frame is pre-drawn separately within an SVG image. We then use CSS to
crop it to a specific frame, and a CSS Animation to move the crop box for
each frame. Since it’s all declarative, Gecko and the compositor process
can handle the animation very efficiently.

[image: filmstrip]

A demo is worth 10,000 words, so check out Jared’s SVG Filmstrip Demo
 to see how this works in detail. (Since it’s all
based on web technologies, you can view-source and see the same technique
running in your browser that we use in chrome.)

Of course, nothing is ever simple! There’s a lot of work that goes into
getting these assets ready. First, our visual designers prototype an
animation in Adobe After Effects. It then goes through a process of design
iteration and user testing. (Is is distracting? Does it communicate what we
want? Too fast? Too slow?) The animation is then exported to an SVG file,
but the markup from Adobe is usually not very good. So we use SVGO
 to optimize it, often further hand-tune the
SVGO output, and finally tweak it to make use of the dynamic context-fill
 color specified from
the browser’s CSS.

Phew! But thankfully, as a user, you can just enjoy the finished result.
We’d like to refine the creation process, but overall it’s a pretty
powerful and flexible technique that we’ll be using more and more.
Recent Changes

Menus/structure:

   - Lots  of minor
    bugfixes
    to
    various
    aspects
    of the earlier
    changes
    we made
   . Thanks to
   contributors Jeongkyu Kim (bug 1376484) and Adolfo Jayme (bug 1376097) for
   their work!
   - Flexible spacers are now available in customize mode
   . This is the
   first step towards having the location field be centered in the navbar, as
   part of the Photon design.
   - Work on the Page Action panel is progressing
   . We gave a
   prototype sneak-peek at the All-Hands (see Photon Newsletter #8), but it’s
   not quite ready to land yet.
   - Made the Library button work correctly in the overflow panel
   

Photon Engineering Newsletter #8 (Super Ultra Mega All-Hands edition)

[Justin Dolske]

(via
https://dolske.wordpress.com/2017/07/05/photon-engineering-newsletter-8/)

Oh boy ! Do I have some great updates
for Newsletter #8 ! But
seriously, this is a huge update…
San Francisco All-Hands

[image: foxbot.jpg]

This past week Mozilla brought together nearly 1300 employees and
contributors to San Francisco for an “All-Hands” – 4 days of intense
hacking on improving Firefox. We’re a globally-distributed organization
(and that works really well for us), but periodically bringing people
together physically is a great way to get a burst of focused productivity,
take advantage a high-bandwidth / low-latency communication medium
(talking!), and build stronger sense of community, team-work, and
excitement. There is some crazy-good stuff coming for Firefox 57 – of which
Photon is just one part.

The Photon team is small by comparison (about 15 engineers), but we made
some huge progress towards getting Photon implemented. Our goal is to be
“feature-complete” by August 7th, and we are solidly on track. That should
allow us to spend most of the time between then and the Firefox 57 release
(November 11th) fixing bugs, applying a high-degree of polish, and as much
general front-end performance improvements as we can.


[image: mayostage]

[image: photonhacking1]

[image: photonhacking2]

Recent (and Upcoming) Changes

In these updates I usually focus exclusively on work that has _landed_ in
Nightly. Stuff that’s real and you can play with today. This week I’m going
to include all of the work that happened at the All-Hands, even though some
of it hasn’t landed just yet. Consider it a taste of what’s to come in the
next few weeks.

Menus/structure:

   - Built the prototype for adding the ability for the user to pin
   frequently-used items from the Page Action menu
    into the URL bar.
   This work adds a context menu to items in the action menu to control this.
   The prototype also added Page Action menu entries for Pocket
    and Screenshots
    (and as a next
   step, their existing buttons in the navbar will be removed). Eventually
   there will be an WebExtensions API so that Addons can extend this menu (but
   that work may not make 57).
   [image: pageactionprotoi.png]
   - The bookmark star has moved
    into the URL bar.
   This (as with Pocket and Screenshots, mentioned above) is part of our work
   to consolidate actions you perform with the page into the (wait for it)
   Page Action menu.
   - The sidebar button is now in the toolbar by default
   . This gives easy
   one-click access to toggle the sidebar. We’ve found a surprising number of
   people use the sidebar – and it’s a great place for addons to expose things
   – so Photon makes it a first-class citizen in browser UI.
   - Customize Mode got a few updates. Its general style has been refreshed
   for Photon , and
   we’ve removed  the
   “grid” style around the edges and shrinking-animation when opened. Also,
   the info panel that’s shown the first time a user enters customization mode
   (which helps explain that you can drag’n’drop items to move them around)
   has been replaced 
   with a Photon critter – the Dragondrop. I hope you can appreciate this
   delightfully terrible pun. 
   [image: empty-overflow-pa...@2x.png]
   - The Library panel will now show Bookmarks
    and Downloads
   . (Bookmarks are
   already in Nightly, Downloads was built during the week but needs code
   review before landing).
   - We also fixed  a
   number  of random
    polish
    bugs
    here
    and
    there
   . “Polish” bugs
   are changes that are not implementing new features, but are just fixing
   smaller issues with new or existing features. We’ll be 

Photon Engineering Newsletter #7

[Justin Dolske]

(via
https://dolske.wordpress.com/2017/06/22/photon-engineering-newsletter-7/ )

Lucky you, here’s Photon update #7
!

Let’s start off with a fresh new video that gives an overview of what we’re
doing with the Quantum and Photon projects. If you’re not already running
Nightly , but are willing to live on the
cutting-edge, this would be a great time to give it a spin! Get involved to
help us test out everything that’s new, and experience some of these great
improvements first-hand!
https://www.youtube.com/watch?v=tJG278nX6dM

Mozilla All-Hands

Next week, everyone at Mozilla will be gathering in San Francisco for our
biannual All-Hands meeting. The Photon team will be using it as a repeat of
our Toronto Work Week (as covered in Photon Update #2
).
So we’re going to be super-busy hacking on Photon. We’ve got even more
great stuff coming up, and I can’t wait to talk about it in Photon Update
#8. But… The intense focus means that I might not get that update out until
the following week. I think the wait will be worth it. 


Recent Changes

Menus/structure:

   - As mentioned in the last update
   ,
   the Photon menus/structure pref has been enabled by default
    on Nightly. We’ve
   had a number of issues filed by Nightly users (thanks for the bug
   reports!), and fortunately the were no huge surprises. As a bonus, Talos
   reported performance wins from the new menus.
   - The library panel now has a “View Pocket List” item
    and looks more
   polished . The
   synced tabs view also got a small update
   .
   - Subviews in menu panels now scroll correctly
    when necessary.
   (You can see this, for example, in the History view when you have lots of
   history entries.)
   - Coming soon: more updates to the library panel
   , page action panel
   , and moving the
   bookmarks star (back) to the URL bar
   .



Animation:

   - Updated arrow-panel animations
    are going through
   review this week.
   - Users on macOS will notice that panel open/close animations are much
   smoother, as a result of a platform fix
   . (You’ll see more
   improvements soon, from the item above, as well as another platform fix
    to add a beautiful background blur to the panel).
   - Work continues on animations for the downloads toolbar button,
   stop/reload button, and page loading indicator.



Preferences:

   - The revised reorganization
    is actively being
   worked on, and is undergoing review this week.
   - Search in preferences was enabled by default in Nightly.
   - Searching now highlights matching menuitems
    with an arrow,
   and works inside subdialogs
   .



Visual redesign:

   - Another community contribution: Oriol removed an small, unexpected line
    that was
   appearing at the top of some windows. Thanks for the patch!
   - Firefox will now automatically enable
    its touch mode
   (which increases the size of various UI to make it more touch-friendly)
   when used in Windows 10 Tablet mode.
   - The dark toolbar that previously landed for Windows 10 is now coming
   to macOS . (This
   just landed, and if it sticks will be in Friday’s Nightly build.)
   [image: Screen Shot 2017-06-22 at 4.27.25 PM]



Onboarding:

   - The onboarding tour content has landed and been polished
    to match the UI
   spec. You can click the Fox icon in about:home to give it a try! Currently
   it has 5 tours for existing (non-Photon) features — Private Browsing,
   Add-ons, Customization, Searching, and setting your Default Browser. These
   are planned to ship in Firefox 56 (for users installing Firefox for the
   first time). Additional tours will next be implemented for Firefox 57, to
   introduce new Photon features to existing Firefox users.
   - The onboarding tour now has UI to allow hiding it
    (so users 

Photon Engineering Newsletter #6

[Justin Dolske]

(via
https://dolske.wordpress.com/2017/06/15/photon-engineering-newsletter-6/)

More exciting progress this week! Here’s Photon update #6
!
New Menus

Work on the new Photon menus has reached the point where we’re ready to
turn them on by default (for Nightly). Bug 1372309
 is tracking the last
remaining work (mostly test fixes), and you should see this happen in
tomorrow’s Nightly. Up until now you’ve needed to manually enable the
“browser.photon.structure.enabled” pref to play with the new menus – you’ll
no longer need to flip that pref as it will already be enabled.

The biggest change you’ll notice is that the application menu (a.k.a. the
“hamburger menu”) contents look different. Instead of a grid of icons, it’s
a linear list of commands. Opening the menu and entering submenus is much
snappier than before. Here’s the new look on Windows 10 (left) and macOS
(right):

[image: menus]

The overflow menu (under the “>>” icon) has existed for a long time now,
normally it’s only shown when the window is so narrow that we run out of
space to show all the toolbar icons. You can now pin items to it
permanently, as the new destination for commands you want easily accessible
without taking up toolbar space. (Previously you could do this by adding
items to the hamburger menu. That’s no longer customizable.)

[image: overflows]

There are also some minor related changes to Customization Mode, which now
shows the overflow menu as a customization target instead of the old
hamburger menu.
Recent changes

Menus/structure:

   - Enabling the new menus, as mentioned above.
   - The sidebar toolbar button no longer has a panel dropdown, instead it
   just toggles the display of the sidebar (you can change which sidebar is
   shown from inside the sidebar itself).
   - Various smaller styling/polish fixes to the different panels and
   toolbar items have landed and will continue to land this week.
   - WebExtension browser actions will now be pinned to the overflow panel
    instead of the
   hamburger menu (though we are aware of at least one remaining issue
    with this).



Animation:

   - The Photon-themed download icon
    landed, this was
   spun out of the main download animation bug to start landing pieces as
   they’re ready.
   - Work continues on animations for downloads toolbar button, stop/reload
   button, and page loading indicator. We’re working through some performance
   issues with the latter two — these animations are triggered during our
   performance test suites, and we see some impact to the measurements.
   - New arrow-panel animations are underway. We’re updating the way panels
   and menus animate when they’re opened and closed. On macOS we’re
   temporarily removing the current animation entirely, while we await
   platform improvements that allow us to get the effect we want in a way that
   performs well.



Preferences:

   - QA-sign off received for the old preferences shipping in Firefox 55
   (which have not been the default on Nightly since landing the new
   preference reorg).
   - Search followups are largely complete, and we are enabling
    the search
   feature this week.
   [image: search-prefs-demo]



Visual redesign:

   - We got some good contributions from community member UK92! Thanks!
  - Updated two of our in-content pages (about:about
   and
  about:rights )
  to use the new Photon style.
  - With maximized windows on Windows 10, the window control buttons now
  span  the
  entire height of the tabstrip, eliminating a small gap.
   - Landing updates to the sidebar styling
    (header and
   search box)
   - Updated  the
   Synced Tabs button icon in the toolbar.
   - Starting work on changing the color of the titlebar on macOS (making
   it darker, similar to Windows 10).



Onboarding:

   - Lots of discussion and decisions, finalized scope and content for
   Firefox 56 tour.
   - De-scoped automigration, and are instead moving ahead with a manual
   import option accessible from the new Activity Stream page.
   - Simplified tour and notification logic
   - Outstanding technical issues resolved and a few 56 tour contents are
   ready to land this week. No more blank tour overlay in Nightly!



Performance:

   - Startup improvements:
  - Captive portal initialization has been delayed
   so that NSS
  

Photon Engineering Newsletter #5

[Justin Dolske]

Via https://dolske.wordpress.com/2017/06/08/photon-engineering-newsletter-5/

Time for a solid update #5 !
So far the Photon project appears to be well on track — our work is scoped
to what we think is achievable for Firefox 57, and we’re generally fixing
bugs at a good rate.
Search Box?

If you’ve been paying attention to any of the Photon mockups and design
specs floating around, you may have noticed the conspicuous absence of the
search box in the toolbar (i.e. there’s just a location field and buttons).
What’s up with that?

[image: win10mock]

For some time now, we’ve been working on improving searching directly from
the location field. You can already search from there by simply entering
your search term, see search suggestions as you type, and click the icons
of other search engines to do a one-off search with them instead of your
default. [The one-off search feature has been in Nightly for a while, and
will start shipping in Firefox 55.] The location bar now can do everything
the search box can, and more. So at this point the search box is a
vestigial leftover from how browsers worked 10+ years ago, and we’d like to
remove it to reclaim precious UI space. Today, no other major browser ships
with both a location field and search box.

That said, we’re being careful about understanding the impact of removing
the search box, since it’s been such a long-standing feature. We’re
currently running a series of user studies to make sure we understand how
users search, and that the unified search/location bar meets their needs.
And since Mozilla works closely with our search engine partners, we also
want to make sure any changes to how users search is not a surprise.

Finally, I should note that this is about removing the search box as the
default for _new_ Firefox users. Photon won’t be removing the search box
entirely, you’ll still be able to add it back through Customize Mode if you
so desire. (Please put down your pitchforks and torches. Thank you.) We’re
still discussing what to do for existing users… There’s a trade-off between
proving a fresh, clean, and modern experience as part of the upgrade to
Photon (especially for users who haven’t been using the search box), and
removing a UI element that some people have come to expect and use.


Recent Changes
Menus/structure:

   - Hamburger panel is now feature complete!
  - An exit/quit 
  menu item was added (except on macOS, as the native menubar handles this).
  - A restyled zoom control
   was added.
  - One small feature-not-yet-complete: the library subview is reusing
  the same content as the library panel, and so won’t be complete until the
  library panel itself is complete.
  - A number of smaller bugs and regressions fixed.
   - Initial version of the new Library panel
    has landed
  - It still needs a lot of work, items are missing, and the styling
  isn’t done. Landing this early allows us to unblock work in
other areas of
  Photon (notably animations) that need to interact with this button.
  - We haven’t placed it into the toolbar by default yet. Until we do
  so, if you want to play with it you’ll need to manually add it from
  Customization mode.
   - We’re getting ready to enable the Photon structure pref by default on
   Nightly, and are just fixing the last tests so that everything is green on
   our CI infrastructure. Soon!


Animation:

   - Landed a patch 
   that allows us to move more of our animations to the compositor and off of
   the main thread. Previously, this optimization was only allowed when the
   item’s width was narrower than the window, now it’s based on available
   area. (Our animations are using very wide sprite sheet “filmstrips” which
   required this — more about this in a future update).
   - Work continues on animations for downloads toolbar button, stop/reload
   button, and page loading indicator. The first two have gone up for review,
   and unfortunately we found some issues with the plan for the downloads
   button which requires further work.

Preferences:

   - Finalized spec
    for
   the preferences reorg version 2. The team will now begin implementation of
   the changes.
   - The team is working on improving search highlighting in
   about:preferences to include sub-dialogs and fixing some highlight/tooltip
   glitches.
   - The spec for Search behavior
    is
   also being finalized.

Visual redesign:

   - One of the most obvious changes this week was the removal of the
   window drag space 
   

Photon Engineering Newsletter #3

[Justin Dolske]

(via
https://dolske.wordpress.com/2017/05/30/photon-engineering-newsletter-3/)

Three! Time for update number three! Ah-ah-ah…


Let’s get straight to it.
Recent Changes
Menus/structure:

   - Work on the new application menu is nearing completion. Edit controls
    and Firefox
   Account status 
   have been added, along with keyboard navigation
   . The “exit” and
   “zoom” controls are the last remaining features to implement.
   - The new overflow menu panel is done, except for polish and bug fixes.
   - The above are still behind the browser.photon.structure.enabled while
   we finish initial development, but we expect to turn them on by default (in
   Nightly) in the next couple of weeks.
   - The new sidebar switcher
    has landed. You
   can change what’s displayed in the sidebar (bookmarks, history, synced
   tabs) from at control at the top of the sidebar itself.
   - Work on the new Library button is starting.

Animation:

   -  Work continues on animations for downloads toolbar button,
   stop/reload button, and page loading indicator – but these haven’t landed
   yet.

Preferences:

   -  Searching within preferences is taking shape on Nightly! It now comes
   with the right highlight color
   , and
tooltips for sub-dialog
   search results. 
   - User testing of the updated reorg is under way.

Visual redesign:

   - Toolbar changes included new toolbar button hover and active
   background styles ,
   increased vertical padding
   , and a new back
   button design .
   Work on toolbar button and location bar style is nearly complete.
   - CSS changes for compact and touch modes
    has landed (but
   needs more plumbing before it’s activated).
   - Lots of small regression fixes.
   - History sidebar style changes being worked on.

Onboarding:

   - The skeleton of the onboarding overlay system add-on is under review
   . This will
   initially be used to introduce new Firefox users to some of the great
   features of Firefox they might not otherwise know about. Later, we’ll be
   using this same framework to help introduce existing Firefox users to the
   changes coming in Firefox 57. Here’s a short GIF from the prototype showing
   what the experience is like, starting from a badge on the new-tab page:
   [image: onboarding.gif]
   - Other improvements to the first-run experience are planned to ship in
   Firefox 55: a better download page, updated stub installer, removing the
   default-browser prompt, and a less intrusive data-privacy notice. We want
   to help new users start using Firefox without annoyances or hassle.

Performance:

   - More rigorous reflow tests have landed for window opening, tab opening
   and tab closing. More tests coming up for windows and tabs
   , and the
   AwesomeBar .
   - Mike Conley started his first The Joy of Profiling
   
   episode. (And if you’re interested in profiling, don’t miss Ehsan’s
talk on Gecko
   and the Native Profiler
   !)
   - A reduction of main thread IO
    during early
   startup, and yet more
    startup
    improvements
   .
   - Upcoming work to delay NSS initialization until after first-paint.



That’s it for now. More next time!


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

Photon Engineering Newsletter #2

[Justin Dolske]

(via
https://dolske.wordpress.com/2017/05/23/photon-engineering-newsletter-2/)

That’s right! Time for another Photon Engineering Newsletter! (As I
gradually catch up with real-time, this update covers through about May
16th).

May got off to a busy start for the Photon team. As I mentioned in last
week’s update, the team has largely shifted from the planning to
implementation, so visible changes are starting to come quickly.
Work Week

A particularly big event was the Photon team gathering in Mozilla’s Toronto
office for a work week. About 50 people from Engineering, UX, User
Research, and Program Management gathered, from all over the world, with a
focus on building Photon. Mozilla operates really well with
distributed/remote teams, but periodically getting together to do things
face-to-face is super useful to work through issues more quickly.

[image: photonww_shorlander_small]

It was really terrific to see so many people coming together to hack on
Photon. We got a lot done (more on that below), saw some great demos, and
the energy was high. And of course, no workweek is complete
 without UX creating
some fun posters:

[image: 57small]

One important milestone reached during the week was setting the initial
scope for what’s going to be included in Photon (or, more bluntly, what’s
NOT going to be part of Photon when it ships in Firefox 57). We’re still
refining estimates, but it looks like all the major worked planned for
Photon can be accomplished. Most things placed in the “reserve backlog”
(meaning we’ll do it if there’s extra time left, but we’re not committing
to do them) are minor or nice-to-have things.

This is probably a good spot to talk a little more about our schedule
. Firefox 57 is the release
that Quantum and Photon are targeting. It’s scheduled to ship on November
14th, but there are important milestones before then… September 22nd is
when 57 enters Beta, after that point it’s increasingly hard to make
changes (because we don’t want to destabilize Firefox right before it
ships). August 7th is when Nightly becomes version 57. This is also our
target date to be complete with “major work” for Photon. This might seem a
little surprising, but it’s due to the recent process change

that removed Aurora. Under the old release schedule, August 7th is when
Nightly-57 uplifted to Aurora (beginning ~12 weeks of stabilization before
release). We want to keep the same amount of stabilization time (for a
project as big as Photon there is _always_ fallout and followup work), so
we kept the same calendar date for Photon’s target. This doesn’t mean we’ll
be “done” on August 7th, just that the focus will be shifting from
implementing features to fixing bugs, improving quality, and final polish.

And now for the part you’ve all been waiting for, the recent changes!
Recent Changes

Menus/structure:

   - The page action menu (aka the “…” button at the end of the URL bar)
   got the first menu items added to it
   , Copy URL and
   Email Link. More coming, as this becomes the standard place for “actions
   you can perform with this page” items.
   [image: actionmenu_first]
   - The new hamburger menu is coming along, although still disabled by
   default (via the browser.photon.structure.enabled pref). Items for
   character encoding, work offline, and the devtools submenu have been added
   to it.
   - The new overflow menu (also disabled by default, same pref) is nearing
   completion with 2/3 of the bugs fixed. This menu is now shown in customize
   mode (instead of the old hamburger menu); so instead of only showing icons
   that couldn’t fit in the navbar (e.g. because you made your window too
   narrow), it’s the new place you can customize with buttons you want to be
   easily accessible without always taking up navbar space.

Animation:

   - When rearranging tabs in the tabstrip, a snappier animation rate
    is now used.
   - Work continues on animations for downloads toolbar button, stop/reload
   button, and page loading indicator – but these haven’t landed yet.

Preferences:

   - The “Updates” section of preferences now shows
    the current
   Firefox version.
   - Good progress at the workweek on fixing the first set of bugs
    needed to enable
   searching within preferences.
   - UX is working on some further changes to the reorganization that we
   believe will improve it.

Visual redesign:

   - The new styling for the location and search bars
    landed.
   - The stop/reload button
    has been 

Re: Quantum Flow Engineering Newsletter #5

[Justin Dolske]

On Tue, Apr 18, 2017 at 4:22 PM, Ehsan Akhgari 
wrote:

> All in all we have a lot of ongoing projects and they each have
> different scales and different degrees of risk associated with them, and
> we are trying hard to be really careful on what project depends on what
> other project to try to protect ourselves from cases where project X
> doesn't make it in time taking project Y down with it.  :-)
>
>
In short, we're trying to avoid Quantum entanglement. :D :D

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

Re: Quantum Flow Engineering Newsletter #5

[Justin Dolske]

On Tue, Apr 18, 2017 at 1:19 AM, Jack Moffitt  wrote:

> > Another really nice effort that is starting to unfold and I'm super
> excited
> > about is the new Photon performance project
> > , which is a
> focused
> > effort on the front-end performance.  This includes everything from
> > engineering the new UI with things like animations running on the
> > compositor in mind from the get-go, being laser focused on guaranteeing
> > good performance on key UI interactions such as tab opening and closing,
> > and lots of focused measurements and fixes to the browser front-end.
>
> I think the order of operations here is unfortunate. What we'd prefer
> is that WebRender land first, and then Photon be designed around what
> is possible in the GPU-backed world.


That's a complete non-starter. Photon work is already underway, and there's
a _ton_ of work to do for the 57 release.

Blocking Photon on another major project landing first would mean canceling
Photon for 57.

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

Re: unowned module: Firefox::New Tab Page, help me find an owner

[Justin Dolske]

Can you follow up with me in separate email about what posts you're
concerned about?

I've done most of the rejection moderation on the list, and usually reply
to people explaining why and where a better venue would be. Most stuff that
has been moderated is exactly what's listed there as being off-topic, and
that's fairly uncommon. Obvious spam gets silently plonked, but that's
presumably not what you're talking about.

This thread, had it been posted to firefox-dev, would very clearly be
on-topic and not rejected.

Justin

On Wed, Mar 22, 2017 at 7:35 PM, Karl Tomlinson  wrote:

> Benjamin Smedberg writes:
>
> > This is not the list for this question. Please respect this question to
> the
> > firefox-dev list.
>
> https://wiki.mozilla.org/Firefox/firefox-dev says "Anyone can post. By
> default, posts will be reviewed by a moderator before being sent to the
> list."
> bit in fact some unclear set of posts are redirected to /dev/null, even
> when
> contributing to the goal and abiding by the rules.
> ___
> 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: Heads Up: /storage upgraded from version 1.0 to 2.0

[Justin Dolske]

It would be useful to know if most of those users are just downgrading the
previous version (N-1 for release, N-7 for ESR), and how quickly they
return to a current release (assuming they do!).

This would help inform to what degree we need to support (and test!) the
myriad combinations of upgrade-downgrade-reupgrade combinations.

I also wonder how much of user-reversion is driven by addon incompatibility
(which will improve in Firefox 57 with WebExtensions), but I'm not sure how
we would answer that.

Justin

On Thu, Mar 16, 2017 at 12:15 PM, Benjamin Smedberg 
wrote:

> I apologize for the delays in bug 1246615. It fell off my radar with a
> series of trips. I've set up a meeting tomorrow to at least identify who is
> responsible for this decision, because it's not exactly me. I analyzed some
> data in the bug which I'll repeat here.
>
> Here is an analysis of the patterns of people downgrading:
> https://gist.github.com/bsmedberg/1af70857106bfe29128a0e8d0b656804 - this
> analysis was reviewed by chutten
>
> users that switched channels at all: 0.48%
> users that reverted to an older version: 2.55%
> users that reverted to an older version, staying on the release channel:
> 2.19%
>
> Downgrades are more prevalent than I thought, and channel-switching is not
> a primary factor in downgrades. So the ideas that we would mostly solve
> this problem by giving channels separate profiles appears to be false.
>
> I still believe that we should do our best to make some set of downgrades
> seamless for the user (if perhaps with some reversion to prior data or
> duplicating). And that showing people a banner warning is user-hostile in
> the sense that if they downgraded it was probably for a reason and so they
> aren't going "back". What I'd like is some clearer guidance about how much
> we should support downgraders and how much engineering effort we should put
> into making downgrade as painless as possible.
>
> --BDS
>
>
> On Wed, Mar 8, 2017 at 9:40 AM, Ehsan Akhgari 
> wrote:
>
> > On 2017-03-07 8:02 PM, Ben Kelly wrote:
> > > On Tue, Mar 7, 2017 at 6:09 PM, Xidorn Quan  wrote:
> > >
> > >>> This major version change is downgrade-incompatible, so IndexedDB and
> > >>> DOM cache won't work in an older version if their profile has been
> > >>> upgraded.
> > >>> IndexedDB is also used internally, so stuff that depends on it likely
> > >>> won't work too.
> > >>> There's bug 1246615 [2] where you can find a discussion related to
> this
> > >>> issue.
> > >>
> > >> It would probably be a good idea to backup the old files when
> upgrading,
> > >> so that old version can at least pick the backup file to use.
> > >>
> > >
> > > Maintaining downgrade compatibility is a lot more complex than people
> > think
> >
> > Yes.
> >
> > > and we have zero test support for it.
> >
> > This part isn't entirely true.
> >
> > The full picture is a bit more complex.  Some components have supported
> > full downgrades with automated tests running on the infrastructure for
> > years.  Examples are the cookie manager and the permission manager.
> > Other components have intentionally decided that it's OK to not maintain
> > backwards compatibility, for example, IndexedDB.  In other places,
> > people (myself included) have just not been careful enough and have
> > (either intentionally or unintentionally) landed code that isn't
> > downgrade compatible.
> >
> > It's certainly true that in general there is no tests that would catch
> > you if you land code that breaks a downgrade scenario, and over the
> > years it has become quite clear that maintaining a downgrade-compatible
> > browser is impractical.
> >
> > I agree with Ben, Jan and others that this situation is unsustainable,
> > and we have to do something about it.  I also agree with Xidorn about
> > how bad it is that we risk destroying data from the very subset of our
> > user population who go out of their way to help us by testing changes on
> > newer builds and risk losing their data when going back to an older
> build.
> >
> > To be perfectly honest, the situation in bug 1246615 is quite
> > frustrating.  I no longer understand what we are waiting for in that
> > bug.  It seems like that bug is being scope creeped into a larger plan
> > (based on comment 29 there) and still unclear what that exactly means,
> > and here we are now: while Firefox 55 rides the trains, we *will*
> > destroy our community's browsing data as they help us test Firefox.
> >
> > Benjamin, can we please address this with the urgency it deserves?
> > Thank you for your attention.
> >
> > Cheers,
> > Ehsan
> >
> ___
> 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: The future of commit access policy for core Firefox

[Justin Dolske]

Similar to "r+ with fixes" are cases where a patch (or patch series)
requires reviews from a multitude of people. Which means variable delays in
getting reviews, during which things may slightly bitrot or be trivially
modified based on feedback from other reviewers. Code refactorings are one
example of this. Having to re-request review from everyone, perhaps
multiple times, would seem pretty painful. :)

>From previous discussions, it sounded like there was a middle ground in
still requiring all landings to go through automation (i.e., a strong link
between what actually landed and what was posted in the bug), but allow
some slop in what was formally reviewed (i.e., a weak link between last
review and what's was asked to land.) The automation might at least require
that you can't land a "r=sparky" unless "sparky" did at some point grant
r+. At the very least, this makes it somewhat easier to compare what landed
with what was last reviewed (with current tools, thanks to ReviewBoard's
revision diffing).

I suppose this policy also implies no more "Typo fix, no bug" landings. But
I never really liked those anyway, so I'm fine with that. Bugs are cheap! :)

Justin

On Thu, Mar 9, 2017 at 3:11 PM,  wrote:

> On Friday, March 10, 2017 at 10:53:50 AM UTC+13, Mike Connor wrote:
> > (please direct followups to dev-planning, cross-posting to governance,
> > firefox-dev, dev-platform)
> >
> >
> > Nearly 19 years after the creation of the Mozilla Project, commit access
> > remains essentially the same as it has always been.  We've evolved the
> > vouching process a number of times, CVS has long since been replaced by
> > Mercurial & others, and we've taken some positive steps in terms of
> > securing the commit process.  And yet we've never touched the core idea
> of
> > granting developers direct commit access to our most important
> > repositories.  After a large number of discussions since taking ownership
> > over commit policy, I believe it is time for Mozilla to change that
> > practice.
> >
> > Before I get into the meat of the current proposal, I would like to
> outline
> > a set of key goals for any change we make.  These goals have been
> informed
> > by a set of stakeholders from across the project including the
> engineering,
> > security, release and QA teams.  It's inevitable that any significant
> > change will disrupt longstanding workflows.  As a result, it is critical
> > that we are all aligned on the goals of the change.
> >
> >
> > I've identified the following goals as critical for a responsible commit
> > access policy:
> >
> >
> >- Compromising a single individual's credentials must not be
> sufficient
> >to land malicious code into our products.
> >- Two-factor auth must be a requirement for all users approving or
> >pushing a change.
> >- The change that gets pushed must be the same change that was
> approved.
> >- Broken commits must be rejected automatically as a part of the
> commit
> >process.
> >
> >
> > In order to achieve these goals, I propose that we commit to making the
> > following changes to all Firefox product repositories:
> >
> >
> >- Direct commit access to repositories will be strictly limited to
> >sheriffs and a subset of release engineering.
> >   - Any direct commits by these individuals will be limited to fixing
> >   bustage that automation misses and handling branch merges.
> >- All other changes will go through an autoland-based workflow.
> >   - Developers commit to a staging repository, with scripting that
> >   connects the changeset to a Bugzilla attachment, and integrates
> > with review
> >   flags.
> >   - Reviewers and any other approvers interact with the changeset as
> >   today (including ReviewBoard if preferred), with Bugzilla flags as
> the
> >   canonical source of truth.
> >   - Upon approval, the changeset will be pushed into autoland.
> >   - If the push is successful, the change is merged to
> mozilla-central,
> >   and the bug updated.
> >
> > I know this is a major change in practice from how we currently operate,
> > and my ask is that we work together to understand the impact and
> concerns.
> > If you find yourself disagreeing with the goals, let's have that
> discussion
> > instead of arguing about the solution.  If you agree with the goals, but
> > not the solution, I'd love to hear alternative ideas for how we can
> achieve
> > the outcomes outlined above.
> >
> > -- Mike
>
>
> How will uplifts work? Can only sheriffs land them?
>
> This would do-away with "r+ with comments addressed". Reviewers typically
> only say this for patches submitted by people they trust. So removing "r+
> with comments" would mean reviewers would need to re-review code, causing
> an extra delay and extra reviewing load. Is there some way we can keep the
> "r+ with comments addressed" behaviour for trusted contributors?
>
> 

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

[Justin Dolske]

Do we have any data on existing content usage of -moz-appearance? Or is
this a "ship it and see what breaks" kind of thing?

I have the vague recollection that this is something that might have
non-trivial usage (especially and specifically "-moz-appearance: none"), so
just want to make sure that's been considered. Otherwise yay for removing
this from the web. :)

Justin

On Fri, Feb 10, 2017 at 2:27 PM, Mats Palmgren  wrote:

> Summary: add support for the CSS UI property 'appearance:none | auto' with
> '-webkit-appearance' as an alias.  Unship '-moz-appearance'.
>
> 'appearance:none' works exactly as '-moz-appearance:none' -- it turns off
> the native theme for elements that have one.  'appearance:auto' (the
> initial value) makes an element have its default appearance.  We are
> currently shipping '-moz-appearance' with a large number of other values,
> such as 'button', 'range', 'radio' etc.  '-moz-appearance' will continue to
> work exactly as is, but will now be restricted to UA and chrome style
> sheets, i.e. it will *not* be available to web content.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1333482
>
> Spec: https://drafts.csswg.org/css-ui-4/#appearance-switching
>
> Platfrom coverage: All
>
> Estimated release: 54 (tentatively)
>
> Preferences: layout.css.appearance.enabled for
> 'appearance'/'-webkit-appearance' (enabled by default),
> layout.css.moz-appearance.enabled for '-moz-appearance' (disabled by
> default).  All these properties are available to UA and chrome style sheets
> though, regardless of the preference settings.
>
> Devtools bug: None needed, I think.
>
> Status in other implementations: No other UA implements the unprefixed
> 'appearance' as far as I know.  Edge implements '-webkit-appearance:none'
> but no other values, nor do they implement it unprefixed.  WebKit/Blink
> implements '-webkit-appearance' with a plethora of values, much like we
> currently do for '-moz-appearance'.  I don't know what their plans are for
> 'appearance' and/or restricting the number of supported values.
>
> I think the fact that Edge currently only ships '-webkit-appearance:none'
> proves that's all that is needed for web compat.  I tend to think we should
> also implement the unprefixed property though, because that's what the CSS
> spec says and I don't think it'll have any negative impact in terms of web
> compat (I admit I'm not 100% certain of that though, but we can adjust as
> needed).
>
> Tests: Reftests and mochitests included.
> ___
> 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 implement: HTML5 element

[Justin Dolske]

What's the expected experience if chrome code uses this feature? (In a
chrome window, interaction with a content window isn't the thing I'm
wondering about.)

Justin

On Tue, Dec 20, 2016 at 3:56 PM, Tim Nguyen  wrote:

> *Summary*:
> The *HTML  element* represents a dialog box or other interactive
> component, such as an inspector or window.
> It will initially be implemented behind a pref.
>
> *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=840640
>
> *Link to standard*: https://html.spec.whatwg.org/multipage/forms.html#the-
> dialog-element
>
> *Platform coverage*: All
>
> *Estimated or target release*: Firefox 54
>
> *Preference behind which this will be implemented*:
> dom.dialog_element.enabled
>
> *DevTools bug*: None yet, although I'm not sure how we can make DevTools
> more useful here ?
>
> *Do other browser engines implement this?*
> Shipped: Chrome (since version 37)
> Considering: Edge ( http://status.modern.ie/dialogelementformodals )
>
> *Tests*:
> https://github.com/w3c/web-platform-tests/blob/master/
> html/dom/interfaces.html#L1835
> https://github.com/w3c/web-platform-tests/tree/master/
> html/semantics/interactive-elements/the-dialog-element
> ___
> 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: Visual Studio 2017

[Justin Dolske]

Until we officially support it, can we have mach print out a warning (w/
link to a bug number or wiki page) if you try to build with it? (And, of
course, with some opt-in mechanism to use it anyway.)

ISTR in the past it was relatively common for people who upgraded (or were
just installing the latest on a new system) to run into mysterious failures
and get frustrated.

Justin

On Wed, Nov 16, 2016 at 5:26 PM, Gregory Szorc  wrote:

> Microsoft announced Visual Studio 2017 RC today. As always, there are some
> compelling reasons to support the new version. They have blogged
> extensively about performance improvements around compiling/linking and IDE
> interactions, which are always exciting.
>
> If you install VS2017 RC today, configure won't detect it. Even if you have
> environment variables set, configure still barfs because paths of things
> within the installation have changed.
>
> Bug 1318143 (alias: vs2017) has been established to track making everything
> work with VS2017.
>
> At this time, we have no timeline for transitioning shipped Firefox
> binaries to VS2017. Obviously we need to wait for VS2017 final. After that,
> we'd likely need some compelling reasons to undergo the transition. We
> will, however, stand up VS2017 builds (likely no to few tests) in
> automation as a tier-2 platform so developers have visibility into VS2017
> compatibility. Bug 1318193 tracks that.
> ___
> 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: Removal of B2G from mozilla-central

[Justin Dolske]

On Fri, Sep 30, 2016 at 3:31 AM, Gabriele Svelto 
wrote:

>
> Since gonk is a widget on its own, during the internal discussions about
> it I - and others who worked on B2G - repeatedly asked for the gonk
> widget to be left in the code even after the removal of all the
> B2G-specific APIs (as a tier3 platform obviously).
>

Respectively, it seems like these requests were ultimately not included in
the final decision. The announcement was pretty clear about "Mozilla’s
Platform Engineering organization needs to remove all B2G-related code from
mozilla-central" and that the community "will need to fork Gecko and
proceed with development on their own, separate branch". Pending any
clarification of that decision, I should think a full removal of this code
would remain the default course of action.

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

Re: Reproducible builds

[Justin Dolske]

On Sun, Jul 17, 2016 at 9:38 AM, David Bruant  wrote:

>
> The second point sort of solves them both. As part of making things
> verifiable, Mozilla could publish a program that makes byte by byte
> comparison only on files that matters after unzip. If they're not that
> important, .chk files could be ignored (blacklisted from the comparison).
> Same for file timestamps.
> That would be acceptable IMHO since a backdoor cannot be hidden in .chk
> files or file timestamps (right?).
>

It's not unreasonable, but I'd be a wary of having to have an asterisk with
caveats explaining that you should trust us that the non-reproducible bits
don't actually matter. Reproducability shouldn't depend on having to do a
code audit to understand impact of excluded things.

That said, my understanding of .CHK files is that they're just library
checksums required for FIPS140 certification (iirc intended to guard
against accidentally corrupted code emitting broken crypto). I think we
generally no longer care about FIPS certification of Firefox, and so should
consider just nuking this stuff in Firefox. We've certainly talked about
doing this before, because it's caused pain in other cases. (Judging from
1181814 NSS itself still cares about this for use in other products.)

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

Re: MXR permanently offline, please transition to DXR

[Justin Dolske]

This reminds me of a password manager bug we fixed 9 years ago (379997!),
where password manager would "helpfully" delete a saved HTTP login if it
got a 403 response upon using it. Unsurprisingly, this was a a terrible
idea that caused your saved logins to disappear when a site was glitchy.

Seem like it would be tough to find a solution to rewrite history/bookmarks
that works when servers are nice, but also ignores servers that are
naughty. Maybe this is addon-fodder for advanced users who want to
mass-edit bookmarks and history.

Justin

On Thu, Jun 30, 2016 at 4:55 PM, Robert O'Callahan 
wrote:

> In theory responses 301 and 308 mean "permanent redirect" so the browser
> could do that for those responses.
>
> In practice you'd need a lot of data to convince yourself that Web
> developers haven't screwed this up too badly. Maybe 308, being newer, is
> not compromised...
>
> Rob
> --
> lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
> toD
> selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
> rdsme,aoreseoouoto
> o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
> lurpr
> .a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
> esn
> ___
> 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: [Go Faster] WebCompat Go Faster Add-on

[Justin Dolske]

I'm not really clear what part of those docs covers my questions. Either
I'm missing it, or my question wasn't clear...

I'm asking because this is code shipping to end-users, so I'd expect it to
adhere to basically the same engineering standards as code that ships as
part of baseline Firefox. AFAIK this is the first time that's really been a
question -- our other system addons (Hello, Pocket) started off in Firefox,
and just changed their delivery vehicle.

To be more specific:

* Who are the people that will be reviewing code that ships in this addon?
I don't see anything in the docs about code review or who can do it. Will
there be a module? Would the relevant platform reviewers be used when
shimming in DOM APIs?

* The docs do expand a bit on testing, but it sounds like a one-time QA
signoff. That's an important part, but I don't see anything about automated
/ ongoing tests (against product code or website code). For example, if a
Gecko change breaks something the addon is relying on, when will that be
noticed? Or if the addon's patch for a site stops working (or, worse,
breaks it!) due to a change the site deploys after the addon is released,
when will that be noticed?

* Similarly to correctness testing, how is performance testing dealt with?

Justin

On Mon, Jun 27, 2016 at 12:09 PM, Cory Price <cpr...@mozilla.com> wrote:

> The answer was focused on the policy question which should be covered for
> the most part in the documentation. With respect to individual roles and
> responsibilities for this add-on, I've added it to the agenda in the
> aforementioned team check-in.
>
> On Mon, Jun 27, 2016 at 11:45 AM, Benjamin Smedberg <bsmedb...@mozilla.com
> > wrote:
>
>>
>> On Mon, Jun 27, 2016 at 2:26 PM, Cory Price <cpr...@mozilla.com> wrote:
>>
>>>
>>> On Mon, Jun 27, 2016 at 11:05 AM, Justin Dolske <dol...@mozilla.com>
>>> wrote:
>>>
>>>> What's the policy for reviews and testing with this addon?
>>>>
>>>
>>> You can see the current process for deploying things in the Go Faster
>>> documentation (Wiki <https://wiki.mozilla.org/Firefox/Go_Faster>, Release
>>> Process
>>> <https://docs.google.com/document/d/1x27I7hAmWDWiqk3o3YC3fklhE3N59bdgHCQHF5p_lkU/edit#>
>>> ).
>>>
>>> I've also added this to our system add-on pipeline
>>> <https://trello.com/b/moJCpVCD/go-faster-system-add-on-pipeline> which
>>> we discuss in our weekly meetings (invited Mike/Justin).
>>>
>>
>> This seems like an inadequate answer to the particular question: who in
>> particular is the module owner of this code, who is responsible for doing
>> code review? And who is the QA/QE lead for this addon and what kind of
>> systems will be used to determine whether a particular webcompat tweak is
>> working both before before and after deployment?
>>
>> --BDS
>>
>> --
>> Benjamin Smedberg
>> Engineering Manager, Firefox
>>
>>
>
>
> --
> Cory Price
> /ckprice
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: WebCompat Go Faster Add-on

[Justin Dolske]

What's the policy for reviews and testing with this addon?

Justin

On Mon, Jun 27, 2016 at 10:51 AM, Mike Taylor  wrote:

> As discussed in the "Platform + Web Compat" session in London, the
> webcompat team intends to build a Go Faster Add-on to give us the ability
> to quickly respond to high profile site compatibility issues in the coming
> quarter(s).
>
> The intent is to be able deploy short-term fixes for high-impact,
> user-facing problems while we work on medium- to long-term fixes (in Gecko,
> or with partners and top sites), without needing to wait on trains.
>
> I've written an explainer doc, with use cases and requirements here:
>
> 
>
> Comments welcome, thanks.
>
> --
> Mike Taylor
> Web Compat, Mozilla
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: "passive" option for AddEventListenerOptions

[Justin Dolske]

How will a developer know when it would be worthwhile to mark their event
listener as passive? Do we perhaps log something to the console?

Justin

On Wed, May 4, 2016 at 3:19 PM, Kartikaya Gupta  wrote:

> Summary: Authors can declare in their addEventListener call that the
> listener will not be calling preventDefault() on the event. This
> unlocks certain performance optimizations.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1266066
>
> Link to standard:
> https://dom.spec.whatwg.org/#dom-addeventlisteneroptions-passive -
> note that this intent email is specifically about the "passive" flag;
> the AddEventListenerOptions dictionary and addEventListener
> modifications were already implemented in bug 1266194. I don't recall
> seeing an intent email for that but maybe I missed it.
> There is also an explainer doc at
> https://github.com/WICG/EventListenerOptions which might be easier to
> read for those already familiar with DOM events.
>
> Platform coverage: all platforms
>
> Estimated or target release: Hoping to get it in Firefox 49. I wrote
> the patches today (they were pretty small) hence combining the intent
> to implement and ship into this email rather than sending two separate
> emails.
>
> Preference behind which this will be implemented: none at the moment
>
> Other browsers: See
> https://github.com/WICG/EventListenerOptions#status-of-implementations
> ___
> 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 deprecate: MacOS 10.6-10.8 support

[Justin Dolske]

On 5/3/16 12:21 PM, Gregory Szorc wrote:


* The update server has been reconfigured to not serve Nightly updates to
10.6-10.8 (bug 1269811)


Are we going to be showing some kind of notice to affected users upon 
Release? That is, if I'm a 10.6 user and I update to Firefox 48, at some 
point should I see a message saying I'll no longer receive future updates?


Justin

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

Re: Changes to bugzilla "plugins" product

[Justin Dolske]

It's fine to keep it as-is for now, but I think the goal should be to get
rid of it (and possibly Tech Evangelism :: Addons too) for the same reasons
as Benjamin noted in his first email.

Seem like most of this component's original intent (naming aside) is
covered by those new components. Compatibility issues with the
WebExtensions APIs themselves would go in Toolkit::WebExtensions (or
possibly a new :: WebExtensions:Compatibilty if someone feels the
distinction is important). Otherwise I'd expect "issues in Firefox that
affect extensions" to live in an appropriate component where the right
people can see them. For example, if some bug in the JS engine broke
Extension X, that should just be filed in Core :: JavaScript Engine. (And
we already have an "addon-compat" keyword to flag/track such bugs globally.)

Justin

On Mon, May 2, 2016 at 3:59 PM, Andrew McKay  wrote:

> I agree, let's just leave its name as it is for now.
>
> On Mon, May 2, 2016 at 3:54 PM, Matthew N.
>  wrote:
> > On Mon, May 2, 2016 at 3:43 PM, Emma Humphries  wrote:
> >>
> >> Andrew, can you do a pass over the bugs since Jan 1st and, and let's
> >> rename this FFx::Add Ons Compatablity so that it's clear it's not
> plugins.
> >
> >
> > Extensions and plugins are both types of add-ons so renaming makes it
> less
> > clear as it then includes plugins and themes.
> >
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to bugzilla "plugins" product

[Justin Dolske]

Will Firefox :: Extension Compatibility also be rolled into this new ::
Other component?

(There are ~700 open bugs there still, most of which look pretty stale.)

Justin

On Mon, May 2, 2016 at 11:53 AM, Benjamin Smedberg 
wrote:

> There used to be a bugzilla.mozilla.org product called "Plugins". This
> product has been renamed "External Software Affecting Firefox" and its
> component structure has been greatly simplified.
>
> It is usually not helpful to track defects in 3rd-party software in the
> Mozilla bug tracker. The only time we want to track those defects is when
> we want to make explicit outreach efforts because those defects affect
> Firefox users.
>
> There were previously almost a hundred different "components" for fine
> classification of these bugs. This was not producing good results and
> caused confusion for many people filing bugs. So I've asked for most of
> these components to be retired, and now there will be just three components:
>
> "Flash (Adobe)" - for bugs in Adobe Flash. I am triaging this list and
> working with Adobe when necessary.
> "OpenH264" - I believe Maire Reavy's team triages this component for bugs
> that affect our deployment of OpenH264 with Cisco.
> "Other" - For defects in basically all other 3rd-party software, including
> other NPAPI and GMP plugins, Firefox extensions, and other software such as
> antivirus tools, that may affect Firefox. I am triaging these bugs as
> necessary.
>
> --BDS
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: ICU proposing to drop support for WinXP (and OS X 10.6)

[Justin Dolske]

On 4/30/16 1:26 PM, L. David Baron wrote:


So I think we should take option a': Drop XP and Snow Leopard support
on trunk and push ESR builds to the non-ESR update channel on XP and
Snow Leopard through the life of 45 ESR.


I think enough of our users are on Windows XP that decisions about
dropping Windows XP are not a purely engineering decision.  (Do we
still have more Windows XP users than we have on all non-Windows
platforms combined?)  Pushing those users to ESR without buy-in from
all parts of the organization will likely lead to worse engineering
problems than having to support XP (e.g., having to support 45ESR
substantially longer).


I know you and Henri know this, but because I've seen it come up in a 
number of other places...


Moving XP users to ESR is not, by itself, a solution. All moving users 
to ESR does is allow them to keep running a supported Firefox for a 
little bit longer than immediately dropping it. (Equivalently, it allows 
the dropping XP support in the code a bit earlier than the final EOL 
date in Firefox.)


Once an EOL decision on XP has been reached, we may (or may not!) opt to 
coordinate that with an ESR release. I'd note that we didn't do that 
with the recent OSX 10.6-10.8 desupport, and ISTR having not done that 
for some other platform in the past because it means maintaining 
build infrastructure for an extended period.


In other words, these are details of what to do with XP users after a 
product decision has been made to actually end support.


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

Re: [Bug 1224726] High memory consumption when opening and searching a large Javascript file in debugger.

[Justin Dolske]

On 4/11/16 4:06 PM, Lawrence Mandel wrote:

On Monday, 11 April 2016, Mike Taylor  wrote:


On 4/11/16 5:04 PM, Mats Palmgren wrote:


He touched 283 bugs in the last 48 hours, most of which are FIXED.



If anyone in the QA org reads this list, maybe they could reach out and
teach him how to more effectively contribute?

(I see "[bugday-20160323]" from <
https://quality.mozilla.org/event/bug-verification-day-109/>.)



Good thinking.

Florin - Does anyone on your team know this contributor?


Looks like Gijs replied in 
https://bugzilla.mozilla.org/show_bug.cgi?id=1255526#c21, and the 
contributor's last comment for the day was acknowledgment that he'd stop.


In addition to the "spam" tagging, I'll note that if people see a 
disruptive/abusive account we can also temporarily disable accounts 
(with a custom message they'll see when they try to log in, for example 
a gentle message asking them to stop and to contact us to reenable).


You can ask for a BMO admin in #bmo.

Justin

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

Re: Triage Plan for Firefox Components

[Justin Dolske]

A few comments, although I think others have touched on some of this
already.

I think my biggest concern is that this is conflating triage and
prioritization, which complicates things and introduces ambiguity. For
example, what would it even mean to have a "triage: fix-now" bug that's
also a P5? I'd much rather leave prioritization to the priority field. I'm
similarly dubious about the value of "not-urgent" and "wishlist". In part
because those also imply priorities, but also because this phrasing seems
like just kicking the can down the road on "making a decision".

It would seem simpler to just have a triage +/-/? flag to indicate if a
decision on triage has been made. Although we're still kind of tap-dancing
around what to do with the inevitable pile of "we just won't be able to fix
this soon bugs" -- I'm not sure a subtle triage flag effectively
communicates intent to people that don't live inside Bugzilla like we do.
It wouldn't be any worse than the status quo (and so is fine to trial), but
it should really just be a new status/resolution... The existing "WONTFIX"
and "INVALID" often convey the wrong meaning, a more accurate (and
gentler!) "DEFERRED" or "INACTIVE" or $BIKESHED_HERE is something I'd like
to see for this common condition.

I don't really understand the 3-month auto-timeout of bugs back to an
untriaged state. This seems like it's just creating work and makes Bugzilla
annoying. Nor is a one-size-fits all solution right here -- large /
long-term and small / short-term project areas will have different needs.
Grooming the list of triaged, prioritized bugs is important for teams to
do, and we should encourage them to do so, but starting off with this being
automatic seems premature.

I'm also concerned about bolting on yet more UI, which makes Bugzilla even
_more_ obtuse and complicated. But given all the feedback on the current
proposal, I suppose it's not worth commenting on here because I presume
this would all change anyway. This also seems like it should just be a
separate project.

Justin


On Tue, Mar 29, 2016 at 1:07 PM, Emma Humphries  wrote:

> tl;dr
>
> In Quarter Two I'm implementing the work we’ve been doing to improve
> triage, make actionable decisions on new bugs, and prevent us from shipping
> regressions in Firefox.
>
> Today I’m asking for feedback on the plan which is posted at:
>
>
> https://docs.google.com/document/d/1FFrtS0u6gNBE1mxsGJA9JLseJ_U6tW-1NJvHMq551ko
>
> Allowing bugs to sit around without a decision on what we will do about
> them sends the wrong message to Mozillans about how we treat bugs, how we
> value their involvement, and reduces quality.
>
> The Firefox quality team (myself, Mike Hoye, Ryan VanderMeulen, Mark Cote,
> and Benjamin Smedberg) want to make better assertions about the quality of
> our releases by giving you tools to make clear decisions about which bugs
> must be fixed for each release (urgent) and actively tracking those bugs.
> What We Learned From The Pilot Program
>
> During the past 6 weeks, we have prototyped and tested a triage process
> with the DOM, Hello, and Developer Tools teams.
>
> Andrew Overholt, who participated in the pilot for the DOM team, said, “A
> consistent bug triage process can help us spread the load of watching
> incoming bugs and help avoid issues falling through the cracks."
>
> During the pilot, the DOM team uncovered critical bugs quickly so that
> people could be assigned to them.
>
> The pilot groups also found that the triage process needs to be fast and
> have tooling to make going through bugs fast. It’s easy to fall behind on
> triage for a component, but if you stay up to date it will take no more
> than 15 minutes a day.
>
> You can find the bugs we triaged during the pilot by looking for
> whiteboard tags containing ‘btpp-’.
>
> It is also important to have consistent, shared definitions for regression
> across components so triagers do not waste effort on mis-labeled bugs.
> Comments?
>
> I am posting this plan now for comment over the next week. I intend to
> finalize the triage plan for implementation by Tuesday, April 5th. Feedback
> and questions are welcome on the document, privately via email or IRC
> (where I’m emceeaich) or on the bugmast...@mozilla.org mailing list.
> Timeline
>
> January: finish finding component responsible parties
>
> February: pilot review of NEW bugs with four groups of components, draft
> new process
>
> Now: comment period for new process, finalize process
>
> Q2: implement new process across all components involved in shipping
> Firefox
> Q3: all newly triaged bugs following the new process
>
> -- Emma Humphries, Bugmaster
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: MOZ_LOG_FILE and MOZ_LOG_MODULES are now the environment variables for logging

[Justin Dolske]

On 3/24/16 9:54 AM, Ralph Giles wrote:

On Mon, Mar 21, 2016 at 9:13 AM, Honza Bambas  wrote:


tl;dr: Start migrating to use of MOZ_LOG_* instead of NSPR_LOG_*.  Don't
worry about backward compatibility tho, when MOZ_LOG_* is not set, we
fallback to NSPR_LOG_* values.


Could this be an opportunity to shorten NSPR_LOG_MODULES to just MOZ_LOG?


+1 to MOZ_LOG. It's better than bad, it's good.

Justin

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

Re: Intent to implement: W3C WebAppSec credentialmanagement API

[Justin Dolske]

On 3/14/16 3:01 PM, Martin Thomson wrote:


The actual benefit is something that is only realized once a site puts
in the effort required.  That is small, yes, but we're seeing sites
actively avoid password managers, hence the aggressive heuristics, and
rAC is much more likely to work for that, since it's implemented and
deployed already.


This is the key issue, IMO, which makes me not interested in having 
Firefox implement this API.


Far too many sites either simply don't care about user password 
management (ie, they do problematic things that could easily be fixed), 
or actively take steps to intentionally break password managers. In the 
past we considered this an advocacy/evangelism problem, and it was 
deemed the site's responsibility to play nice. That's worked poorly, and 
sucks for users. We now believe that we have to assume a adversarial 
environment: it's our job to serve as the user's agent and do whatever 
it takes to work on a site.


If there's interest in assisting sites that want to play nice, I think 
it would be better to start with documenting a set of cross-browser 
"best practices" that they can follow, for the standards and 
implementations that exist today.


I'd also note that Mozilla Labs tried going down a similar path in the 
past, with Account Manager -- see 
https://hacks.mozilla.org/2010/04/account-manager-coming-to-firefox/. 
The team involved in that did a _lot_ of outreach with sites and web 
developers. I remember it as having a somewhat tepid reception... 
Especially around sites not wanting to cede any UX control to the 
browser in the signup/login/logout experience, and some industries being 
very disinterested doing anything beyond what was mandated by 
regulations (ie, they saw doing anything outside their rulebook as 
adding legal risk).


Justin


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

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Justin Dolske]

I don't think it's entirely unfair -- both sets of numbers have their
place. OS X is an important platform, but it's also true that these older
OS X releases represent a tiny portion of our overall userbase.

For a few more data points...

Back in Firefox 16 when we dropped 10.5 -- another long-lived and popular
release -- those users represented 17% of our OS X users (or 0.78% of
overall userbase). Dropping 10.6 - 10.8 is about 1.5x the impact
(percentage wise), and so we should think carefully about that, but it's
not significantly out of character for what we've done before.
https://groups.google.com/d/msg/mozilla.dev.platform/aT7hy7YDdqA/j2O0bUnuYMEJ

When we dropped 10.4 (early in the Firefox 4.0 cycle, about a year before
release), it represented 25% of 3.5 users and 17% of 3.6 users. (I don't
see a overall userbase number in the thread.)
https://groups.google.com/d/msg/mozilla.dev.planning/fTpkdYa6uZM/9aPn58hvVa8J

And wy back when we dropped 10.3 (for FF3.0), it represented 16.5% of
OS X users, 0.69% of total user base.
http://groups.google.com/group/mozilla.dev.planning/msg/c19ecb46e27dbf91
http://groups.google.com/group/mozilla.dev.planning/msg/4bd908b72a5e0759

One thing all of these threads show is that there's a lot of noise and
handwringing and doomsayers when we broach the topic of dropping support
for an OS X release. :)

Justin

On Thu, Mar 10, 2016 at 2:25 PM, Mike Hommey  wrote:

> On Thu, Mar 10, 2016 at 01:03:43PM -0500, Benjamin Smedberg wrote:
> > This is notice of an intent to deprecate support within Firefox for the
> > following old versions of MacOS: 10.6, 10.7, and 10.8
> >
> > The motivation for this change is that we have continued failures that
> are
> > specific to these old operating systems and don't have the resources on
> > engineering teams to prioritize these bugs. Especially with the
> deployment
> > of e10s we're seeing intermittent and permanently failures on MacOS 10.6
> > that we are not seeing elsewhere. We get very little testing of old MacOS
> > versions from our prerelease testers and cannot dedicate much paid staff
> > testing support to these platforms. We also have an increasingly fragile
> set
> > of old hardware that supports automated tests on 10.6 and do not intend
> to
> > replace this.
> >
> > This will affect approximately 1.2% of our current release population.
> Here
> > are the specific breakdowns by OS version:
> >
> > 10.6
> >   0.66%
> > 10.7
> >   0.38%
> > 10.8
> >   0.18%
>
> It's unfair to mention those populations by percentage of the global
> Firefox population. What are those percentages relative to the number of
> OSX users? ISTR 10.6 represented something like 25% of the OSX users,
> which is a totally different story (but maybe I'm mixing things with
> Windows XP).
>
> Mike
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing Windows AutoDial aka Remote Access Services

[Justin Dolske]

It being an IE-ism, only used by .015% of sessions, and with a easy
workaround make this sound like and open-and-shut case of "dead".

Justin

On Fri, Feb 19, 2016 at 4:01 PM, Martin Thomson  wrote:

> On Fri, Feb 19, 2016 at 1:07 PM, Patrick McManus 
> wrote:
> > I'd like to remove it
>
> "great or dead"
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: rr chaos mode update

[Justin Dolske]

On 2/14/16 9:25 PM, Bobby Holley wrote:


How far are we from being able to use cloud (rather than local) machine
time to produce a trace of an intermittently-failing bug? Some one-click
procedure to produce a trace from a failure on treeherder seems like it
would lower the activation energy significantly.


And with that... At some point, what about having all *new* tests be 
battle-tested by X runs of rr-chaos testing?  If it passes, it's allowed 
to run in the usual CI automation. If it fails, it's not (and you have a 
handy recording to debug).


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

Re: Touch events enabled on Windows desktop (nightly only)

[Justin Dolske]

On 2/1/16 2:37 PM, Bill McCloskey wrote:


I can imagine it's frustrating if you have one of these devices, but we
have to prioritize how we spend our time. And I don't think it's worth
holding up the whole project for a few percent of users, even if they are
the cool ones :-).


Yep, incremental improvements are good. I don't think this should block 
an E10S rollout for everyone.


But I did want to point it out, because touch-enabled devices are more 
and more widespread, and APZ (responsiveness) is particularly important 
there. And then there's the issue of "I just bought a new 
(touch-enabled) computer and Firefox seems janky" being awkward when 
that new computer probably includes Edge or Chrome for the user to 
compare with and possibly switch to.


So I do think this is something important to fix soon.

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

Re: about:profiles and the new profile manager

[Justin Dolske]

On 12/18/15 1:51 PM, Benjamin Smedberg wrote:


Have you consulted anyone from the Firefox front-end or Firefox UX
team about this already?


As it stands, this is not intended to be product code and so I
specifically advised Andrea not to spend UX/product time on this. It is
still a strict replacement for the old profile manager code which was
very difficult to maintain.


I think it still would have been good to have some UX input on the 
design. It's used commonly enough that we can't drop it, and so it's 
worth giving it some UX attention as part of a quality product.


That doesn't mean it has to be a large project; it's fair to place 
bounds on the work (like making it a strict replacement for the old 
code, and not expanding scope). I think our UX team has been good about 
working within such limitations when needed, and even proposing 
well-scoped improvements that would otherwise have been missed.


(This holds for any piece of UI, really. It's always worth reaching out 
to UX.)


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

Re: Proposal to a) rewrite Gecko's encoding converters and b) to do it in Rust

[Justin Dolske]

On 12/14/15 2:51 AM, Ted Mielczarek wrote:


[...]Obviously this isn't something we like to see, but
we shouldn't let the support of non-Tier 1 platforms guide our decision
making to that extent. Enabling Rust components in Gecko is important
work, and outweighs the value of supporting Firefox on minority
platforms.


+1. We shouldn't be doing any work to maintain Tier-3 platforms, nor 
should they hold us back from modernizing and securing the platforms 
used by the overwhelming majority of our users.


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

Re: Intent to implement and ship: FIDO U2F API

[Justin Dolske]

On 12/2/15 6:48 AM, Richard Barnes wrote:


My initial intent was to propose implementing [1], then implementing [2]
when it's ready.  After all, there's a lot in common, and as you say, the
W3C version will be much nicer.


This seems like like a strange path to take. Why implement both?

From elsewhere in the thread, it sounds like v.1 is basically importing 
a defacto-standard (?), in which case I'd wonder how realistic is it to 
implement a different version later and actually get sites to switch to it.


I'd also wonder just how far off v.2 is... It is something that's likely 
to get to a final spec in a reasonable timeframe (and should we just 
wait for that), or is it so far off in la-la land that it's not actually 
likely to ever be implemented by anyone? Somewhere in between?


Would the v.1 implementation be deprecated by the v.2 implementation, or 
do both need to be carried around forever?


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

Re: Faster Windows builds everywhere!

[Justin Dolske]

On 12/1/15 12:41 PM, Chris AtLee wrote:


Last week we made the same change to the rest of the Windows build
infrastructure. All our Windows builds are now running in AWS. We're seeing
good performance gains there too. On mozilla-inbound, we've reduced opt
build times by at least 45 minutes, and nearly two hours (!!) off of our
PGO build times.


Nice!

What builds/tests have _not_ moved to the cloud? AIUI the two biggies 
are OS X (can't move because OS licensing), and perf tests... How close 
are we to transitioning everything else off MoCo metal?


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

Re: Merging comm-central into mozilla-central

[Justin Dolske]

On 10/23/15 10:22 AM, Benjamin Smedberg wrote:


I'm sorry that it makes you sad, but Mozilla has explicitly decided to
prioritize the bar to entry for Firefox development, and the speed of
development of Firefox, at the expense of Thunderbird (and seamonkey).
And as Firefox development moves faster toward things such as stopping
supporting XUL addons, removing support for heavyweight themes, and even
cutting XUL altogether, we should all expect the impedance mismatch to
become worse. We are not only saying that you don't have to fix
comm-central apps: we're also saying that we don't *want* core
contributors to spend time on comm-central.


+1. Last time this thread came up, I thought the guidance was that core 
contributors (and especially MoCo employees) should explicitly *not* be 
spending time on TB/SM code. Even in the "I'll just be nice and go a bit 
out of my way", because those costs are undervalued and add up.


This isn't out of spite or malice towards those projects, but a 
recognition that we need to focus our extremely limited time and 
resources. We're in a hypercompetitive market with giants (Google, 
Microsoft, Apple) who effectively have infinite time and resources in 
comparison. Constant distractions from our core do no one any good.


[And the same argument applies to things within Firefox as well - there 
are many things we could be doing, but need to aggressively focus our 
efforts on a few things that matter most.]


I'd also reiterate your point that this issue is, unfortunately, likely 
to get much worse as we start making deeper changes to modernize the 
platform (like de-XULification). I already see complaints from TB/SM 
folks about the difficulty in keeping pace today, and I'm not sure how 
those projects will realistically be able to keep up in the future. (And 
so it certainly seems like an odd time to be merging that code into 
mozilla-central.)


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

Re: Building js/xul/css from Firefox faster

[Justin Dolske]

Nice! Out of curiosity, how does "faster" work? Does it just ignore build
targets/directories that involve native code?

FWIW, I benchmarked various no-changes builds with yesterday's m-c, on my
low-end Surface Pro 3 (i3, 4GB)...

mach build: 7:38
mach build browser: 0:43
mach build toolkit: 1:42
mach build faster: 0:22

Big wins!

Justin

On Thu, Oct 1, 2015 at 5:23 PM, Mike Hommey  wrote:

> Hi,
>
> I recently landed a new build backend that, if you opt-in to running it,
> will make your non-C++ changes to Firefox more readily available in
> local builds.
>
> After you built Firefox normally once, and assuming you only changed
> non-C++ code, you can now use the following command for a faster
> incremental build:
>   ./mach build faster
>
> Now, since this is fresh out of the oven, there are a few things to
> know:
> - it doesn't handle removing files
> - it doesn't handle files that would end up outside of dist/bin
> - it doesn't handle a few things like the files from the default profile
> - it currently only works for desktop Firefox
>
> Obviously, this is not an end state, so things will improve in the
> future, but it should work well enough for most day-to-day work for
> desktop Firefox, thus this message.
>
> On my machine, `mach build faster` completes in about 4 seconds for an
> incremental build. This should get even faster very soon.
>
> Additionally, while requiring some manual steps (which bug 1207888 and
> bug 1207890 will help with), it is also possible to use this to build
> desktop Firefox without actually building any C++. Here is how that
> goes:
> - Run `./mach configure` with a mozconfig containing:
>   ac_add_options --disable-compile-environment
> - Download and unpack a nightly
> - Use `./mach python toolkit/mozapps/installer/unpack.py `, where
>is the nightly's firefox/ directory.
> - Move that fully unpacked nightly to $objdir/dist/bin (for mac, that
>   involves more fiddling, because dist/bin is a somewhat flattened
>   version of the .app directory)
> - Ensure the files in $objdir/dist/bin are older than the source files.
> - Run `./mach build faster`.
> - On mac, you will need to run something like (untested)
> ./mach build browser/app/repackage
>
> After that $objdir/dist/bin should contain a bastardized Firefox, with
> xul, js, etc. coming from the source tree, and the remainder still being
> there from the original nightly.
>
> `mach run` should work with that.
>
> Cheers,
>
> Mike
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: dialog=1 for window.open from content

[Justin Dolske]

On 10/1/15 1:34 PM, Mike Conley wrote:


I'm currently working on bug 1095236 - that's an e10s bug for us failing
to open any windows if the features string includes dialog=1 (or
dialog=yes).

According to [1], setting dialog=1 makes a popup window that removes the
min/max/restore buttons, and no "command" menu (the icon usually
appearing in the top left which opens the Restore, Move, Size, etc
options). Note that this is only really apparent on Windows, where we
default to having such buttons on popups.


What does this currently do in non-E10S mode? And what do other browsers 
actually do?


I generally think we shouldn't do too much special here. Especially 
considering that this argument doesn't even make much sense on platforms 
with a radically different notion of "window" (ie, mobile).


ISTR that window.open() once used to allow lots of this kind of stuff 
back in the Web 0.8 days, and its functionality has been pared down over 
the years due to UX and security concerns.


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

Re: About static analyzers on some various projects

[Justin Dolske]

On 9/25/15 7:06 AM, Robert O'Callahan wrote:


[...]I'm not quite sure
what it would take to get those build failures to appear in MozReview but
it should be possible.



The tricky bit is to determine which failures were introduced by the patch,
and just display those, and display them in the context of the patch in
some way that makes sense.


Yeah, I think this needs a solution to be effective.

*begin thousand yard stare*

In a previous life at Sun, all new code was required to pass lint and 
cstyle checks, and it was strictly enforced. Of course, tons of existing 
code did not pass, and so it became an enormous PITA to diff piles of 
output.


At Mozilla, it seems like previous discussions on this kind of thing 
(style and warnings come to mind) have dealt with this at a 
file/directory/module level... Someone fixes up a thing completely, adds 
it to a whitelist, and then it's a simple pass/fail. Could that work 
here too?


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

Re: Considering dropping Talos support for Linux32

[Justin Dolske]

On 9/24/15 6:55 PM, Robert O'Callahan wrote:


FWIW I agree that Talos results for Linux32 are unimportant. Even if there
was a Linux-32-only regression, I don't think it'd be worth our developers
spending time on it.


I agree. Kill them.

https://www.youtube.com/watch?v=5DckrYRSsUA

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

Re: [stats] Counting HTTP/2 domain names

[Justin Dolske]

On 9/10/15 4:55 AM, Patrick McManus wrote:

no - generally we don't do origin based telemetry for privacy reasons


I suppose, if one really wanted to, that this could be approximated on 
the client side... Have the browser track all the HTTP/2 domains it 
connects with, and only report the total in telemetry.


If the hypothesis is that most HTTP/2 connections are from a handful of 
major sites, most clients will report a small number. If the clients 
also reported the total number of non-HTTP/2 domains, I would further 
expect the HTTP/2 count to stay small even for client that do lots of 
broad browsing. (And, conversely, if HTTP/2 is more widely deployed, 
you'd see numbers that are larger and correlate more with the how many 
total sites a user visits.)


Whether this work is worth doing is a separate question. ;-)

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

Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

[Justin Dolske]

On 7/7/15 6:17 PM, David Anderson wrote:

+1 for removing this. Gecko's use is inconsistent, and outside of
Gecko code that does use it, I've never seen it used in any other
codebase. I've never gone to another project and thought, I miss
decorating everything in a way that changes capitalization and
impairs canonical naming.


I don't care strongly about the naming, but this is an important point. 
Jeff's original post was explicit about it too, yet it keeps being 
overlooked.


Whenever style changes are proposed, there's a lot of of knee-jerk 
resistance (omgchange!). It's natural. But the relative anchor point 
here is that the rest of the world manages to do just fine without it. 
And so any stylistic benefits of aFoo feel, well, overstated.


[This is a problem endemic to Mozilla, beyond simple code style. We get 
stuck in ruts and local maxima, and become inflexible to doing things 
differently from how they've always been done.]


Personally, for these kinds of issues, I find it useful to think about 
if we would _add_ the thing if it didn't already exist. And if we 
wouldn't, we should strongly bias towards change unless the costs are 
_clearly_ not worth it.


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

Re: Voting in BMO

[Justin Dolske]

On 6/9/15 2:24 PM, Chris Peterson wrote:


I vote for bugs as a polite (sneaky?) way to watch a bug's bugmail
without spamming all the other CCs by adding myself to the bug's real
CC list.


I think if Bugzilla, with its long and complex history, ever has a hope 
of being untangled into something better, we can't keep every feature 
because of all the possible ways it might be used. :)


Here, I'd suggest that the default should be to _not_ send emails for CC 
changes, unless a user opts into it (and maybe even not even for that, 
it's just spammy for anyone managing lots of bugs. But baby steps...). 
Net improvement, no matter what happens with voting.


I'd agree that voting could be removed. Most people know that it was 
added as a way to counter +1! type comments. But I'd counter that (1) 
it's unclear that it's very effective in that role and (2) I've rarely 
actually seen people telling people to use voting.


We have better tools now with the ability to tag and hide comments 
(https://wiki.mozilla.org/BMO/comment_tagging) which I _do_ see used 
frequently, as well as the ability to entirely disable commenting on 
bugs in extenuating circumstances. I'd like to see those further improved.


That said, there are much bigger issues with Bugzilla's UI, and removing 
voting is probably the smallest possible improvement. But it's probably 
easy to just disable it for a while, and see what happens?


Justin

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

Re: Voting in BMO

[Justin Dolske]

On 6/9/15 7:09 PM, Ehsan Akhgari wrote:


I cannot remember a single instance where I or someone who I know has
used the number of votes on a bug as an input for making a decision, and
that is for good reason, since the number of votes tell you nothing
about how severe a problem actually is, and everything about, well, how
many people have voted for it.


+1.

(omgwait, how do I vote for a email?!)

I think that this is where someone's supposed to point out that the #1 
most-voted-for bug is the MNG bug. And #2 is implement W3C XForms in 
browser and composer.


Justin

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

Re: Intent to implement and ship: document.execCommand(cut/copy)

[Justin Dolske]

On 5/6/15 10:02 AM, Ehsan Akhgari wrote:


1. The scenario that you're describing is already possible on the Web,
through Flash.  However, I have not seen any evidence of this kind of
thing ever occurring in the wild.  Given the fact that people have
literally had years to start trying to do this.  Web sites do have an
incentive to not annoy users, and we have seen how they have largely
stopped doing annoying things such as blocking the context menu in the
past.


Well... Did Flash offer sites a way to to this without user interaction?

I don't know for sure, but I assumed it had to be invoked by a user 
action... I remember a couple of popular URL shortener sites using Flash 
for this, and they always required a conspicuously-extra click on a 
copy to clipboard button. (Entering full-screen had the same 
requirement too, IIRC.)


I think the web sites do have an incentive to not annoy users claim is 
dubious too. Some sites certainly do, but we still see widespread 
annoyance/abuse of features like popups, onbeforeunload traps, playing 
unexpected audio in background tabs. And some legit sites (eg wendys.com 
/ t-mobile.com) kind of abuse geolocation by prompting for it on every 
page upon page load.


This isn't such a severe problem that we have to completely solve it 
right away, but I'd hate to see us painted into a corner where we have 
no options for mitigating abuse or giving our users control.



2. Even if we decided that this is a serious issue that we need to
solve, there is no good solution here.


One off-the-cuff thought would be to place some reasonable restrictions 
on the usage (tab must be in foreground, maybe in response to a user 
interaction), and perhaps provide some (fairly subtle) UI indication of 
when it's invoked. That at least gives the user a chance to see a 
clearer cause/effect.


Or, along the vein of retroactively revoking permissions -- just keeping 
a usage log somewhere. That at least enables motivated/SUMO users to be 
able to discover what site is causing the problem, and then either 
revoke it off or stop going there. Seems like kind of an interesting 
idea that would scale to other seldomly-abused permissions...


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

Re: Excessive inbound bustage

[Justin Dolske]

On 4/21/15 5:26 PM, Mike Hommey wrote:
...

- the biggest backout rate for those authors is 48.8%.


The suspense is killing me. Is it Ehsan?! ;-) ;-)

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

Re: changing the default platform and operating-system on bugzilla.mozilla.org to all / all

[Justin Dolske]

On 4/14/15 8:40 AM, Dave Townsend wrote:

I've gotten used to just
ignoring these fields and reading the bugs instead. I wouldn't feel any
loss if they were just removed from display entirely.


+1. The fields are broadly unreliable, and we should just remove them. I 
think I've seen the whiteboard or summary used more often as a way to 
indicate that a bug is specific to a particular platform.


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

Re: Bug 706103 should be backed out. Theme authors very unhappy

[Justin Dolske]

On 4/3/15 5:53 AM, Philip Chee wrote:


Really? Nobody can reopen a bug except the owner?

[thinks some more]  actually this might come in handy. If some idiot
tries to reopen one of my bugs, I can always slap them down and tell
them this is Mozilla policy.


I'd instead say that the people doing the work are generally in the best 
position to decide how to track that work, and that it's been 
longstanding policy that reopening bugs is almost never the right thing 
to do [The main exceptions being after a backout, or the rare case of a 
patch completely failing to fix an issue.]


This bug is a good example of that -- it's not helpful to treat Bugzilla 
as a battleground or tug-of-war using reopening to express complaints. 
If there's an issue with something that landed, one should either (as 
appropriate) comment in the bug, file a new bug, or start a thread on 
the relevant mailing list (firefox-dev in this case).


I'll also note that it's not constructive to start things off on a 
confrontational foot, with labeling like ridiculous and slapping down 
idiots. Please keep things civil.


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

Re: Intent to deprecate: persistent permissions over HTTP

[Justin Dolske]

It does seem to me that popup-blocking isn't a great fit for this list.
AIUI this started from Chrome's intent to start moving powerful features
to SSL-only (with this being a first step), and allowing popups doesn't
seem like that kind of feature.

It's also worth noting that our popup blocker is not perfect, and there are
various ways around it. So if a MITM attacker wants to inject popups into a
non-SSL page, they'd presumably just do it in a way that doesn't require
exceptions in the first place.

Justin

On Fri, Mar 6, 2015 at 10:31 AM, Ehsan Akhgari ehsan.akhg...@gmail.com
wrote:

 On 2015-03-06 1:23 PM, andreas@gmail.com wrote:


  On Mar 6, 2015, at 6:18 PM, Ehsan Akhgari ehsan.akhg...@gmail.com
 wrote:

 On 2015-03-06 1:14 PM, andreas@gmail.com wrote:


  On Mar 6, 2015, at 5:52 PM, Anne van Kesteren ann...@annevk.nl
 wrote:

 On Fri, Mar 6, 2015 at 6:33 PM,  andreas@gmail.com wrote:

 Is the threat model for all of these permissions significant enough
 to warrant the breakage?


 What breakage do you envision?


 I can no longer unblock popups on sites that use HTTP. The web is a big
 place. It will take a long time for everyone to move.


 I think Anne is not proposing that.  He's proposing blocking persisting
 those permissions.  IOW you would be able to still show popups from these
 websites, but you won't be able to ask Firefox to remember your preference.


 I know but we will break the persisting. The user will be annoyed that
 popup unblocking doesn’t work as expected on HTTP sites.

 I am all for securing dangerous permissions but popups and notifications
 seems more like we are wagging our finger at the user in unhelpful ways.
 Most users will simply think Firefox is broken.


 Notifications are a much newer feature than pop-ups and are not as widely
 used yet, so hopefully with the case of notifications we can stop
 persisting the permission right now without having too many people wonder
 why they can't persist the permission.  Perhaps it makes more sense to
 start with geolocation, fullscreen and pointerlock first.

 One thing to note is that there are still large Web properties which at
 least use geolocation and fullscreen from HTTP (Bing Maps for example for
 geolocation, and player.vimeo.com for embedded vimeo videos usin
 fullscreen).  We should probably start evangelizing this sooner than later
 to those Web sites, and perhaps also to the general developer community
 through a hacks blog post and similar venues.

 ___
 firefox-dev mailing list
 firefox-...@mozilla.org
 https://mail.mozilla.org/listinfo/firefox-dev

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

Re: Permission UI

[Justin Dolske]

I don't actually think about:permissions is a good start, or that it's
implemented most of the complicated bits. Quite the opposite, really: it
was a useful experiment, but has some serious problems. I'd briefly
summarize the two main flaws as (1) manager UIs are generally not great
(they provide some minimal functionality to change settings but are bad at
informing the user what's going on) and (2) it isn't a great fit for the
scopes of various things in the browser (everything from global settings to
exact-url matches, with lots of subtle variations in between), let alone
matching that to a user's mental model.

Philipp Sackl (UX) has been poking at this for a while, and has some
interesting explorations. We can and should definitely do more here, just
not with about:permissions. :)

Justin

On Tue, Mar 3, 2015 at 5:17 AM, Frederik Braun fbr...@mozilla.com wrote:

 The good news is that most of the complicated bits are already
 implemented. See about:permissions.

 Though it operates on hostnames and not origins (bug 1066517).
 ___
 firefox-dev mailing list
 firefox-...@mozilla.org
 https://mail.mozilla.org/listinfo/firefox-dev

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

Re: Tree Status Addon

[Justin Dolske]

On 2/4/15 6:52 PM, Giovanny Gongora wrote:

What is the minimum Firefox version? Because I am using 33 and it says on
AMO that is not available for my Firefox version.


The correct answer here is that Firefox 33 is unsupported and insecure. 
You should either upgrade to Firefox 35 (the current release). Or 
downgrade to Firefox 31.4 (the current extended-support release), but 
presumably that won't help with addon compat.


Justin

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

Re: Migrating defaults from other browsers

[Justin Dolske]

On 1/19/15 4:58 AM, Henri Sivonen wrote:


I think this leads to a more general question:
Is it really a good idea that our profile migrators migrate settings
from other browsers when those settings have been left to the defaults
of those browsers?


My assumption was that we're only migrating customized prefs, since 
otherwise we can't tell the difference between something a user made an 
explicit choice about vs didn't care.


But more broadly, I think we should be pretty conservative with what's 
migrated. A quick skim shows that we're migrating lots of stuff that 
seems low-value (eg browser.underline_anchors), or things that could be 
outright broken (eg permissions.default.image, the UI for which was 
removed!).


So I think it's worth revisiting what prefs we migrate.

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

Re: W3C Proposed Recommendation: longdesc

[Justin Dolske]

On 1/6/15 6:37 PM, Jet Villegas wrote:

The main downside I see is a potential Mozilla removes features used by
disabled people... PR fiasco. I think we can avoid that with a better
proposal that we do support.


I'd be really curious to see if this is actually being used by anyone. 
We're already recording telemetry for context menu usage, so we should 
already have data on how often the context-viewimagedesc entry is clicked...


Blake Winton can get current data, but poking through an older data set 
it seems to have low usage. I don't know what period this older data 
covers, but as a relative comparison I see 7 million Open Link in New 
Tab clicks, 930K Save Image clicks, 5K Set as Desktop Background, 
and zero View Description (ie, longdesc) clicks.


Justin

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

Re: e10s is now enabled by default for Nightly!

[Justin Dolske]

On 11/8/14 1:03 PM, Nicholas Nethercote wrote:

On Sun, Nov 9, 2014 at 12:29 AM,  jmath...@mozilla.com wrote:


Everyone should start familiarizing themselves with the idiosyncrasies of 
debugging three processes at once, it'll be the norm this spring.


Three? I've only seen two...


Chrome, Content, Plugin(s).

Justin

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

Windows 10 package manager

[Justin Dolske]

http://www.extremetech.com/computing/192950-windows-10-will-come-with-a-command-line-package-manager-much-to-the-lament-of-linux-users

With Windows 10, however, we are finally getting an official package 
manager: OneGet. In the current build of Windows 10 Technical Preview, 
you can open up PowerShell and use OneGet to install thousands of 
applications with commands such as Find-Package VLC and Install-Package 
Firefox.


Anyone know how the OneGet works? Are they actually repackaging and 
redistributing Firefox in some new format (which would be, uhm, surprising)?


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

Re: The worst piece of Mozilla code

[Justin Dolske]

On 10/16/14 5:32 AM, Nicholas Nethercote wrote:


I was wondering what people think is the worst piece of code in the
entire Mozilla codebase. I'll leave the exact meanings of worst and
piece of code unspecified...


It's gone now, but I always held a special hate for nsIDialogParamBlock.

http://mxr.mozilla.org/seamonkey/source/embedding/components/windowwatcher/public/nsIDialogParamBlock.idl

It was a horrid XPCOM thing to pass strings around for creating a 
prompt, by way of magic numbers. Want to set the title? Set string #12! 
Or maybe it was #3. They're listed in the completely separate 
nsPIPromptService.idl, but they're confusing (#12 is eDialogTitle, #3 is 
eTitleMessage), and IIRC some are complete lies.


Most of the other original prompting code was similarly bad.

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

Re: Breakdown of Firefox full installer

[Justin Dolske]

On 10/14/14 2:20 AM, Robert Strong wrote:


* (Countries' average) Internet speed dramatically affected conversion
rates: 70% success in the fastest countries and 30% in the slowest

countries.
Note that these conversion rates are from download to hitting the first
run page and there are several factors that dramatically lower the
conversion rate outside of the actual stub installer portion of the
process. When just measuring the conversion rate from clicking install in
the stub installer the conversion rate is actually close to 90%.


Interesting; this is what I was asking about in my other post.

If we're getting ~90% conversion in the stub installer, that implies 
download size improvements may have little effect. A max of the missing 
10%, and presumably some portion of that is due to other factors.


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

Re: Deprecate geolocation and getUserMedia() for unauthenticated origins

[Justin Dolske]

On 10/2/14 1:07 PM, Martin Thomson wrote:

On 02/10/14 11:58, Ehsan Akhgari wrote:

What data specifically?  I'm fairly confident that we can make this
change no matter how many websites use geolocation from
non-authenticated origins.


I believe that usual practice before we remove something we don't like
is to provide some warning.  There are some big sites that use
geolocation from http:// origins.

That said, those sites will continue to work.  It is most likely treated
in the same way as the user rejecting the request for location.


I think Ehsan is only talking about removing the persistent always 
allow permission. The effect of doing so would be that the user would 
simply be prompted each for each request, instead of it being 
automatically allowed. It's not treated as a permission denial, and is 
what happens by default in Firefox.


I'd have no objection to this. We can monitor Input feedback on the 
prerelease channels, before/after the change, to see if it's a problem 
prior to shipping it on release.


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

Re: Intent to implement: image-rendering: pixelated CSS property-value

[Justin Dolske]

On 9/23/14 4:24 PM, Jonas Sicking wrote:


This makes the implementation considerably simpler, which is great.  It
also means that pixelated will essentially just be a
more-interoperable version of -moz-crisp-edges, for the time being.


Would it make sense to have separate properties for scale up and
scale down? With image-rendering being a shorthand for setting both?


Maybe.

We use this property in Firefox's UI, to make favicons look better when 
upscaling on hidpi displays... NN upscaling looks better for tiny icons, 
because smooth algorithms just make them look blurry. I noted in bug 
839923 comment 0 that it's not ideal to have the same behavior for 
downscaling, and the issue tangentially came up again in bug 1041845.


So there's a plausible use case. OTOH, scaling tiny icons is just 
generally not good with either algorithm, so having the capability isn't 
really of much use. There are other scaling algorithms explicitly 
designed to scale small/pixel-art images much better, but AFAIK no 
browser actually implements such a thing.


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

Re: Restricting gUM to authenticated origins only

[Justin Dolske]

On 9/10/14 2:09 AM, Henri Sivonen wrote:


Chrome auto-decides whether the grant is persistent based on whether
the URL is http or https.


Whoa. That's non-obvious and creepy. As a user, I find it creepy for
an UI that looks like a one-time grant to actually do a persistent
grant.


Indeed. I think it's fine for the protocol to influence if persistence 
_can_ be set (i.e., only allowing persistence on secure connections), 
but making it automatic is conflating permission (user choice) and security.


It's particularly egregious on Google Maps... The maps.google.com site 
redirects to https://google.com/maps, which means using geolocation on 
Google Maps in Chrome will automatically allow geolocation for all of 
google.com. I wonder how many Maps users understand or expect that.


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

Re: Intent to implement: Disabling auto-play videos on mobile networks/devices?

[Justin Dolske]

On 8/26/14 6:43 AM, Patrick McManus wrote:


I think it would make a lot of sense to have an explicit low bandwidth
mode that did stuff like this, instead of trying to address it piecemeal.
There's all kinds of stuff that can consume bandwidth, and if we think it's
a real concern then let's directly address it.



I think that's a pretty cool idea - I'm on vacation for another week, can
you file a bug and cc: me? Or I'll do it when I come back.


This would be bug 859998.

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

Re: Intent to implement: Disabling auto-play videos on mobile networks/devices?

[Justin Dolske]

On 8/22/14 10:17 AM, Hubert Figuière wrote:

On 21/08/14 01:29 PM, Wesley Johnston wrote:

Summary: We've had some complaints at times about videos autoplaying on mobile 
devices when sites request autoplay.

[...]

Autoplay waste bandwidth, whether mobile or wifi. In some case it is
more serious than other.


I think it would make a lot of sense to have an explicit low bandwidth 
mode that did stuff like this, instead of trying to address it 
piecemeal. There's all kinds of stuff that can consume bandwidth, and if 
we think it's a real concern then let's directly address it.


Consider the increasingly popular gfycat.com. It offers GIF hosting with 
reduced bandwidth, by encoding as WebM. Example:


  http://www.gfycat.com/SpectacularPerfectCygnet.html (910K WEBM)
  http://giant.gfycat.com/SpectacularPerfectCygnet.gif (10.9MB GIF)

Autoplay makes complete sense in this context, just as every browser 
will autoplay a GIF. If the concern is actually bandwidth, then it 
would be better to avoid/abort loading video _and_ images above some 
arbitrary threshold. Why penalize a 910K video file but not an images 
12x as large? Should be the other way around!


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

Re: Rethinking the crash experience

[Justin Dolske]

On 7/7/14 12:21 PM, Ehsan Akhgari wrote:

We should keep in mind that sometimes due to startup crashes, we don't
get to run any of the code in Firefox, so we can't gate the crash report
submission on that code at least in the case of startup crashes.


Yes. For that, I think we'll need to retain an independent fall-back 
crash reporter as we have today. But being able to handle the normal 
(not a startup crash) case in-product would be nice for a number of 
reasons. I had talked with some folks a long time about about doing 
something similar to what David is proposing, so I think it's generally 
a good idea!


1) Crashes suck and are disruptive for users. Making that less painful 
by minimizing the impact (e.g. trying to restart and recover as 
seamlessly as possible) is a win in general.


2) Being able to integrate the crash-submission flow into the browser 
opens up possibilities for better UX and features, since it's the 
familiar cross-platform environment we all work in. (Currently the crash 
reporters are per-platform native apps, which I think is a big part of 
why they've been unchanged and unpolished for years). One can envision, 
say, a flow where the submission results in a guided troubleshooting 
experience, especially when the signature matches something we know has 
been fixed or has a workaround/solution.


3) E10S will already need something vaguely like this, since a 
content-process crash won't take down the whole browser. (And having the 
native crash report pop up would be weird.) I'm not sure if we know what 
the content-vs-chrome breakdown will be for all crashes with E10S, but 
I'd sorta assume content crashes would be more common, and that UX flow 
will be the one seen more frequently by users.


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

Re: Rethinking the crash experience

[Justin Dolske]

On 7/8/14 9:56 AM, Tobias Besemer wrote:

Am Dienstag, 8. Juli 2014 18:23:00 UTC+2 schrieb Justin Dolske:

2) Being able to integrate the crash-submission flow into the browser
opens up possibilities for better UX and features, since it's the
familiar cross-platform environment we all work in.


Sorry, maybe a little bit OT ... ;-)
Would it be possible to report back to Mozilla hanging scripts ???


Yes, this is off topic.

Justin

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

Re: Intent to ship: Hyperlink Auditing (a ping)

[Justin Dolske]

On 5/16/14, 6:38 AM, Curtis Koenig wrote:

Would this be disabled in Private Browsing? If not that might be
perceived as negating one of the reasons users have for using that
particular feature.


Private Browsing mode is about not storing _local_ data from your 
activities. It is explicitly not an anti tracking mode because that's 
extremely difficult-to-impossible to do robustly just on the client, and 
would be a misleading claim and/or result in a browser most people would 
think is broken. E.G. as already noted in this thread, sites can already 
do this without a ping.


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

Re: Memory management in features implemented in JS

[Justin Dolske]

On 3/19/14 4:39 PM, Kyle Huey wrote:


We are discovering a lot of leaks in JS implemented DOM objects.  The
general pattern seems to be that we have a DOM object that also needs
to listen to events from the message manager or notifications from the
observer service, which usually hold strong references to the
listener.


This little hack works for the observer service:

http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser-plugins.js#1226

It uses a weak reference with the observer service, plus a dummy strong 
reference (via addEventListener()) to automatically manage the 
lifetime... When the node/document does away, so does the event listener.


Dunno if the message manager has a way to do this, but perhaps it 
wouldn't be hard to add. That it, it's kind of a hack and a cleaner 
solution would be nice.


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

Re: Always brace your ifs

[Justin Dolske]

On 2/22/14 7:18 AM, Kyle Huey wrote:

If you needed another reason to follow the style guide:
https://www.imperialviolet.org/2014/02/22/applebug.html


I don't really disagree with bracing being a good idea, but I'll be 
contrarian here. Mandatory bracing probably wouldn't have helped; since 
you could still easily end up with:


  if ((err = SSLHashSHA1.update(hashCtx, foo)) != 0) {
  goto error;
  }
  if ((err = SSLHashSHA1.update(hashCtx, bar)) != 0) {
  goto error;
  }
  goto error;
  if ((err = SSLHashSHA1.update(hashCtx, baz)) != 0) {
  goto error;
  }

There may even be an argument against bracing, in this specific case, 
since it makes the repeated line slightly less visually obvious. I think 
a remark about this was made in the recent style guide discussion: when 
reviewing code, one often starts off by scanning for abnormal patterns 
(hence of value of having consistent style, so abnormal isn't 
conditional on which file you're in). But I don't really care. I think 
the correctness-impact is usually exceedingly rare/minor, and the 
ensuing style flamewars distract focus from better solutions.


For example, _both_ the Apple bug and my example above would have been 
flagged by tools that warn about incorrect/misleading indentation. 
Unsurprisingly, gps proposed doing this in the recent style guide thread 
around automatic brace-insertion (and the risks thereto). 
Dead/unreachable code analysis should have caught both as well, even 
with correct indentation.


But really, the best way to fix this would be to use a macro:

  err = SSLHashSHA1.update(hashCtx, foo);
  SSL_ENSURE_SUCCESS(err, err);
  err = SSLHashSHA1.update(hashCtx, bar);
  SSL_ENSURE_SUCCESS(err, err);
  err = SSLHashSHA1.update(hashCtx, baz);
  SSL_ENSURE_SUCCESS(err, err);

Ok, maybe I'm not being entirely serious. :P

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

Re: ISomething, nsISomething or mozISomething?

[Justin Dolske]

On 2/17/14 12:41 PM, Ehsan Akhgari wrote:

On 2/17/2014, 9:15 AM, David Rajchenbach-Teller wrote:

Do we have naming conventions for new xpcom interfaces?

I believe that I have seen all three forms on the tree. I need to pick
one for my new bug. Which one should I pick?


Avoid ISomething since that means something on Windows.


And of course nsSomething means something on OS X (well, ok, NSSomething).


I think most people still name their interfaces nsISomething.  The
mozISomething naming convention seems to be specific to the storage
code, some of places code, and things such as mozIApplication or
mozIJSSubScriptLoader.  The first two are generally written by the same
people, and I can't find a lot of other examples other than the two
names I mentioned.


I vaguely remember there being some interest in transitioning to a moz 
(Mozilla) prefix instead of ns (Netscape). You may have noticed that 
Netscape is no longer a thing, and so cargo culting around a mysterious 
two-letter prefix is a little weird. OTOH, I've never heard of a 
proposal to switch all nsIFoo to mozIFoo, and so there's so benefit to 
having one consistent prefix instead of two. One might also wonder if it 
would be better to just drop the prefixes entirely, were we to do any 
kind of mass change. Ditto for filenames.


tl;dr: you can keep using nsIFoo unless you have an industrial yak-razor 
and the will to use it.


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

Re: What platform features can we kill?

[Justin Dolske]

On 10/9/13 11:29 AM, Boris Zbarsky wrote:


RDF


We use RDF in Firefox, in localstore.rdf among others I guess.


Right.  We should stop doing that.  ;)


Bug 559505 - localstore.rdf kills ponies

I got hung up on the (ancient) patch there because RDF is baked pretty 
firmly into the XUL Tree API.


(Hey, I just thought of another thing to add to the chopping block.)

Justin

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

Re: Audit your code if you use mozilla::WeakPtr

[Justin Dolske]

On 10/8/13 6:04 PM, Ehsan Akhgari wrote:


This code pattern is another problem -- you need to keep object alive if
you want to do this some other way.  We have an idiom for this kind of
thing in fact (grep for kungFuDeathGrip!)


Would that be a kungFuDeathGrep? (Sorry. Just making weak pun.)

Justin

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

Re: Poll: What do you need in MXR/DXR?

[Justin Dolske]

On 10/2/13 12:33 PM, Erik Rose wrote:


What keeps you off DXR? (What are the MXR things you use constantly?
Or the things which are seldom-used but vital?)


First -- this work is really awesome. DXR already feels like it's close 
to being something I can switch over to. If for no other reason than it 
being omgfast!


Support for image browsing would be super helpful for front-end stuff.

Compare

http://dxr.mozilla.org/mozilla-central/source/toolkit/themes/windows/global/icons

with

http://mxr.mozilla.org/mozilla-central/source/toolkit/themes/windows/global/icons/

(Maybe this is just a bug? In general I'd expect all files to show up 
when browsing a directory.)


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

Re: JavaScript Style Guide. Emacs mode line.

[Justin Dolske]

On 9/10/13 3:09 AM, ishikawa wrote:

 OTOH, code in a strange indentation is hard to touch: during linux
 development around 2.1.1xx, Alan Cox got tired of the spaghetti code of SCSI
 driver subsystem and introduced a revision: that revision consisted only of
   sweeping reformatting of scsi subsystem files. No change except for
 re-formatting.
 It was felt the code could not be improved upon any more without such
 re-formatting.

There are certainly times when reformatting (or refactoring) is needed
and done. But they're generally exceptions.

Developers need to be able to adapt to different code styles. At the
very least, there will always be cases where a project imports an
external library that uses a different style, where people are simply
working on different projects with different styles. That's the relative
landscape that has to be considered.

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

Re: Viewing resource usage of builds

[Justin Dolske]

On 8/23/13 1:16 PM, Ehsan Akhgari wrote:


Finally, this is just a friendly reminder that if you build
mozilla-central and you don't have a machine with at least 4 *physical*
cores, 16 GB RAM, and an SSD, you should upgrade your hardware.


FTR, my Windows machine has 16GB of ram, 4 physical cores, and both SS
and spinning disks.  A debug clobber build takes 34 minutes on the
spinning disk and 31 on the SSD - so the wins of an SSD on my box aren't
quite as large as I was expecting (I suspect the cores and 16GB of ram
is the most important for me, or maybe it's just that my 12 month old
Intel SSD isn't state-of-the-art anymore)


I think judging what the effects of changing one component would be on a
given system is all but trivial.  I just did a clobber build on Windows
on a machine with 12 physical and 24 hyperthreaded cores and 32GB of RAM
in 35 mins.  ;-)


I just did a build on my overclocked 64-core system with 8TB of RAM, 
8-n-1 gigabit ethernet, G500 mouse and OH GOD I CAN SEE FOREVER ;-)


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

Re: Code Review Session

[Justin Dolske]

On 5/28/13 7:39 AM, Benjamin Smedberg wrote:


Bugzilla is our tracking tool of record. I'm personally rather bullish
about bugzilla improvements, now that the 4.2 upgrade is done and we
have solid people working on it and making weekly improvements.


Yeah. It has its share of flaws, but it's also battle-tested, and has 
had significant recent improvements recently. I'd also given up on it in 
the past, but it's on a better path now.


Multiple tools end up being confusing, and reliance on external tools 
carries risk that if they shut down we'll lose important history. (This 
is already Not Fun when spelunking in old Mozilla code, and finding that 
something landed without any bug number to explain what it was doing or 
why, nor context of the thinking or issues that let to the change.)


I think it's fine (good, even!) to have small / experimental projects 
try new things, but the expectation should be that once those projects 
become non-experimental / production, they should return to the usual 
tools. (And we should be improving / expanding the usual tools to meet 
modern requirements.)


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

Re: Proposal to make Firefox open in the foreground on Mac when launched from terminal

[Justin Dolske]

On 5/29/13 3:09 PM, Ehsan Akhgari wrote:

Typically when you use the terminal to open an application on Mac, the
application is opened in the background.


Mmm, indeed. Someone told me long ago this this was a platform 
convention, but it sure is annoying. Seems like a nice refinement to me.


I'd assume that the most common use-case for launching the browser is 
to, well, use the browser. If people don't want -foreground as a 
default, I'd like to understand why. (Loading a test page and focusing 
on console output is fair, and the -background proposed in the bug would 
help.)


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

Re: Geolocation and the Mac

[Justin Dolske]

On 5/21/13 4:45 PM, Doug Turner wrote:


The main difference is that you will get one prompt from the OS the
first time you use geolocation from Firefox -- just like every other
standard Mac application.


Could be a little odd, but as long as it comes up after our own 
permission dialog it should be ok.


I was curious if Safari was pre-cleared for this or not. Looks like it 
isn't -- I triggered geolocation from maps.google.com, then I got 
Safari's prompt for the page, and then an OS prompt regarding Safari was 
presented. Nice that they're playing by their own rules. :)


But, hmm... Slightly worrysome -- I clicked don't allow, and now I 
can't get Safari's geolocation to work. It's own dialog comes up, but I 
never get the OS prompt again (even after restarting the app).


Yikes, this is crappy. The OS only asks once, and then your choice is 
(permanently?) stored in Preferences -- Security  Privacy -- Location 
Services.  I had to google to find this, as Safari just silently passes 
on a failure to the site. I seriously wonder if we should have some UI 
(notification bar?) to note when Core Location fails (and send the user 
to a SUMO page explaining how to reenable it).


Do the Core Location APIs provide a unique error code for when the 
user/OS has blocked permission?


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

Re: Geolocation and the Mac

[Justin Dolske]

On 5/22/13 9:49 AM, Doug Turner wrote:


The Mac has a system where by location services for all apps are managed
in a central place.  We do not work in that system -- we do something
different.  This makes a user's view of how their location information
is being share not complete. :(  And we should change that.


Agreed, I think better integration with OS-provided services is 
generally a swell thing. It just brings a bit of UX complexity in this case.



Do the Core Location APIs provide a unique error code for when the
user/OS has blocked permission?


We know if the access to CoreLocations was denied.  I am not sure if we
can prompt the user again for permission if it was denied in the past.
And if we could, I am not sure I would.  What do you think dolske?


We don't need to trigger the OS prompt again, just provide some info to 
the user to help them understand why Firefox's geolocation isn't working.


The specific concern is that users won't understand that the one-time OS 
prompt can permanently block the browser's geolocation ability on all 
sites. The way Safari works is especially confusing -- the app will 
still prompt the user for permission on a site, but then the OS blocks 
the request. And so it seems like Safari is broken. (Of course if the 
user denies the browser's per-site prompt, this problem doesn't arise.)


So, either (1) the browser's prompt should shown with some help for the 
you told us 'yes' but told the os 'no' make up your mind case, or (2) 
the browser's prompt should never be shown when the the OS won't let it 
work anyway. I don't think #2 is a good choice, because it feels more 
like a silent accidental failure mode than a solid indication of user 
intent.


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

Re: Proposal for an inbound2 branch

[Justin Dolske]

On 5/1/13 8:41 PM, Ehsan Akhgari wrote:

Another disadvantage of project branches in addition to the ones
mentioned before is that it limits/delays the amount of testing that you
can get on Nightly and from all of the developers who run things like
fuzzers on ours code.  Not everyone's project has enough manpower to get
that level of testing on a project branch before their stuff gets merged
to central/inbound.  I personally cannot imagine doing my development in
a project branch silo and deprive myself of the huge advantage that this
kind of testing brings about.


That all depends on how one uses a project branch.

If you use a project branch as a traditional staging area for work that 
is large/complex and merge it infrequently, then yes. Those are 
absolutely real problems.


But if you use a project branch as just a frequently-merged integration 
branch, then I don't see these things as being problems. I think that's 
what gps is proposing -- not the old-school usage of project branches 
(maybe we need a new term?). Such branches would be almost exactly the 
same thing as mozilla-inbound, and we don't worry about those problems 
on inbound. We did exactly this in the past with JS and Services (and to 
a lesser extent with fx-team)... We'd just call them inbound-js and 
inbound-services now.


[AIUI, those teams stopped because inbound was working so well -- why 
spend time running your own branch when m-i is just as good and requires 
no effort? The twist now is that m-i is a victim of it's own success, 
and so we should think about making the costs more directly visible to 
project teams.]


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

Re: Storage in Gecko

[Justin Dolske]

On 4/26/13 11:17 AM, Gregory Szorc wrote:


But, please don't
make consumers worry about things like SQL, schema design, and PRAGMA
statements.


Ideally, yes. But I suspect there will never be a one-size-fits all 
solution, and so we should probably be clear about what it's 
appropriate/intended for (see: prefs today!).



Anyway, I just wanted to see if others have thought about this. Do
others feel it is a concern? If so, can we formulate a plan to address
it? Who would own this?


I'd really like to see a simple, standard way to mirror a JS object 
to/from disk. There would barely be any API, it Just Works. EG, 
something like:


  Cu.import(jsonator2000.jsm);
  jsonator.init(myfile.json, onready);
  var o;
  function onready(aVerySpecialProxyObject) {
o = aVerySpecialProxyObject;
  }
  ...
  o.foo = 42;
  if (o.flagFromLastSession) { ... }

With a backend that takes care of file creation, error handling, 
flushing to disk, doing writes OMT/async, handling writes-on-shutdown, 
etc. Maybe toss in optional compression, checksumming, or other goodies.


It's been on my maybe-some-weekend list for a while. :)

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

Re: Rethinking the amount of system JS we use in Gecko on B2G

[Justin Dolske]

On 4/21/13 4:51 PM, Justin Lebar wrote:


What I'd like to come out of this thread is a consensus one way or another as
to whether we continue along our current path of writing many features that are
enabled on B2G in JS, or whether we change course.


First -- B2G should clearly do whatever it needs to in order to get 
acceptable memory/perf/whatever in the short term. If B2G flops, it 
doesn't matter a damn what it's written in.


That said, I think it's critically important that we're working to make 
JS a acceptable -- nay, _excellent_ -- language/runtime for application 
development for the long run. We can't tell a credible story about why 
people should write HTML5 apps, if we're tearing out swaths of JS in our 
own products. Sometimes dogfooding is unpleasant or hard, but that's the 
whole point.


There will always be a place for C++ (well, until Rust, amirite? ;). 
Either as being the right tool for a specific job, or just because 
someone happens to know it better. But if we end up avoiding JS because 
it's inherently JS, then that's a big strategic problem.


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

Re: Revamping touch input on Windows

[Justin Dolske]

On 4/18/13 5:50 AM, Jim Mathies wrote:


One of the concerns here is that since we do not differentiate the metro
and desktop browsers via UA, the two should emulate each other closely.
The browser would appear completely broken to content if the same UA
sent two different event streams. So we need to take into account how
metrofx works as well.


How does the current/proposed state of affairs compare to other 
platforms (notably OS X and Android)?


While the Metro-vs-Win8 case seems especially important to get right 
(since the same user on the same device may commonly flip between both), 
I'd hope web authors can write/test for on one platform and be 
reasonable able to expect their code to work the same everywhere. It's 
not clear to me how that ties in with what you're talking about.


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

Re: Landing on Trunk - Target Milestone vs. Status Flag Usage vs. Tracking for Future Releases

[Justin Dolske]

On 4/10/13 1:53 PM, Alex Keybl wrote:


Knowing this, why not consider just using the status-flags purely
to track landings and let the team determine how to use target
milestone? Also, why not set the status-flag in general for the
appropriate Firefox release when a patch lands on trunk?


The difference between version-specific status flags (fixed) and
target milestone (along with resolved/fixed) is subtle. [...]


Sounds like there are some details to sort out, but I rather like the 
idea. I _still_ see people confused about what target milestone is, 
and having a consistent mechanism for what gets set for a m-c landing vs 
aurora/beta would sure be nice. Scripts or pseudoflags whose actual 
value is derived from other things might be of use.


I'd question if we really need to keep Target Milestone at all (given 
replacements for how it's used now). I don't see many Firefox/Gecko 
teams using it (let alone consistently). The whiteboard should be 
adequate for indicating aspirational landings.


There is _significant_ value in eliminating/replacing niche workflows in 
favor of a more consistent system that people can actually understand.


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

Re: proposal: replace talos with inline tests

[Justin Dolske]

On 3/4/13 9:36 AM, Gregory Szorc wrote:


If all your tests are declared the same way, then presumably the test
running code would be similar and capturing performance data would
require a single implementation affecting all test suites instead of N
1-off solutions.


We've talked about this before (perhaps in this very newsgroup), as a 
cheap (?) way to get extra perf measurements beyond our current limited 
set of tests, and to avoid having to add a new test suite/framework 
whenever someone wants a metric... E.G. measure the run time of each 
existing test, use scripts to figure out which ones are fairly stable 
over time, then watch for regressions. A chance to begin again in a 
orange land of opportunity and adventure!


But I'd also take the general ability to add a new test as a microbenchmark.


We should unify our test running code as much as possible.


Oh god yes please.

Justin

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

Re: Proposed W3C Charter: HTML Working Group

[Justin Dolske]

On 2/8/13 2:37 PM, L. David Baron wrote:

W3C is proposing a revised charter for the HTML Working Group.
For more details, see:
http://lists.w3.org/Archives/Public/public-new-work/2013Feb/0009.html
http://www.w3.org/html/wg/charter/2012/


Is there a way to see what's changing from the current charter?

Justin

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

Re: Question about Bugzilla bug dependencies

[Justin Dolske]

On 1/7/13 1:02 PM, Chris Peterson wrote:

I've seen some inconsistent usage, so I just wanted to get a group opinion.

If a fix for bug X introduces regression bug Y, should Y block X
(because X is not properly fixed until regression Y is fixed) or should
Y depend on X (because regression Y does not exist without fix X)?


Y blocks X.

I find it easier to remember as X depends on Y (a complete fix for X 
depends on Y)... And then work backward to what to set, since setting 
one for X will set the other for Y. YMMV. ;-)



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

Re: Use of instanceof SomeDOMInterface in chrome and extensions

[Justin Dolske]

On 12/27/12 11:20 PM, Boris Zbarsky wrote:

On 12/27/12 2:49 PM, Justin Dolske wrote:

Hmm. My first reaction is to gently challenge if this really has to
change


Well, it really has to change as exposed to web content (or we have to
convince every single other browser to change behavior and get the
ECMAScript spec changed and so forth).


Meaning we're the exception here? How does this impact web content?


After all, if it's changing a frequently used chrome/addon pattern,
that's a pretty big incompatibility step. And I'd sort of expect an
HTMLAnchorElement to always be an HTMLAnchorElement, without the
creator's context mattering... [1]


Unfortunately, that's not how instanceof works in JS.  Try it with
Object instead of HTMLAnchorElement...
[...]
If HTMLAnchorElement is switched to follow the spec, it will set
isAnchor to false, because the implicit adoptNode during the appendChild
changes the prototype chain in Gecko.


Hmm. This is what makes my head hurt a bit. The common case would, 
apparently, be wanting to know if someElement is a HTMLFoo or not. Which 
seems like it shouldn't matter if it's a Foo in content or a Foo in chrome.


But if Object is already inconsistent here (and unfixable?), maybe it's 
just one of those weird wat cases of JS that we have to live with? 
Seems quite unfortunate, though.


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

Re: Use of instanceof SomeDOMInterface in chrome and extensions

[Justin Dolske]

On 12/27/12 2:18 AM, Boris Zbarsky wrote:


The arguably right way to do the el instanceof HTMLAnchorElement
test is:

   el instanceof el.ownerDocument.defaultView.HTMLAnchorElement

Needless to say this sucks.


Eew, indeed.


So the question is how we should make the above work sanely.  [...]
Other ideas?


Hmm. My first reaction is to gently challenge if this really has to 
change, or if it can't be beaten into submission by some other deep 
magic hack...


After all, if it's changing a frequently used chrome/addon pattern, 
that's a pretty big incompatibility step. And I'd sort of expect an 
HTMLAnchorElement to always be an HTMLAnchorElement, without the 
creator's context mattering... [1]


But I don't understand the problem space well, so I'll just accept for 
the moment that it really really does need to change. :)


One fairly easy (and mechanical?) option would be to add a global helper 
function. Something roughly along the lines of:


  var isIt = checkForDOMInterface(el, HTMLAnchorElement);

  function checkForDOMInterface(el, kind) {
return (e instanceof el.ownerDocument.defaultView[kind]);
  }

That wouldn't be too terrible to do, and is easy to communicate.

A bigger shift might be to change to using existing properties 
(.nodeName? .nodeType?) or add something new?


[1] Tangential curiosity on that expectation... What happens today (and 
in the future), with something like:


  // Hello, I am chrome code adding an anchor to content
  var noob = document.createElement(a);
  gBrowser.contentDocument.body.appendChild(noob);

  // ...later, for an arbitrary node, possibly el === noob
  var isAnchor = el instanceof HTMLAnchorElement;

Justin

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