Re: Phabricator and confidential reviews

[Randell Jesup]

>On Wed, Aug 9, 2017 at 11:32 AM, Mark Côté  wrote:
>
>> I actually like Gijs's proposal, to mirror *from* Phabricator *to* BMO.
>> That way, if you're looking at the bug and want to pull someone in, you CC
>> them; if you're looking at the fix and want to involve someone, you add
>> them as a subscriber which then incidentally lets them view the bug, for
>> background and updates and such.
>
>
>​What if there's not "the" fix but multiple patches? This is quite common
>for security bugs where a testcase that reveals the vulnerability is done
>in a separate patch so it can be checked in after we release the fix. Or
>occasionally bugs like https://bugzilla.mozilla.org/show_bug.cgi?id=1371259
>that had 9 separate patches. Would the same people have to be separately
>subscribed to each?​

I've seen landings (for non-security bugs) that involved up to 100
patches on one bug... or even more.  While that's probably never
happened for a sec bug, multiple patches is not unusual (and in fact
common where there's a test added).

>And don't forget reporter and assignees. Occasionally a reporter not in the
>security group will notice that a patch is insufficient which is nicer to
>find before the patch is committed than after the commit link is added to
>the bug. Sometimes someone other than the official assignee adds a patch
>for an alternate approach to a fix and asks the assignee for feedback,
>though that's uncommon and the assignee could just be manually subscribed
>to the patch at that point.

In fact it's quite common for people who are cc'd other than the patch
writer and reviewer(s) to look at the bug and comment on it, or to
submit an alternate or modified version of a patch previously uploaded.
And as Dan points out, frequently the reporter (when an external
'researcher') will weigh in on the patches being posted or use them to
verify if they fix the problem they found (since many times only they
can reliably reproduce the problem - private test setups, drivers, HW, etc).

>We can wait and see how common the "please subscribe me to the patch"
>requests are, but I suspect they'll be common enough.

Bite the bullet and at least make all CC'd people able to see all
patches, always.  It's needed.

Another aspect of all this that needs to be thought out and verified is
what happens when a non-sec bug becomes a sec bug (and vice-versa,
though I'm far less concerned about that).   When a bug becomes a sec
bug, all patches associated with that bug must become confidential.  And
when a bug moves to be open (not sec-restricted), the patches should
also become open.

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

Re: Moving from xulrunner to firefox SDK

[Myk Melez]

Manish 
2017 August 21 at 23:53
from where can I find the latest firefox SDK version for all the 
platforms eg: windows, linux and mac. Second can the directory 
structure remains the same as earlier like for xulrunner.
There isn't a Firefox SDK, as Mozilla decided to stop supporting the 
embedding use cases that were previously supported by XULRunner.


However, Firefox continues to ship a "private XULRunner" that other 
applications can access via its --app command-line flag, which means 
that you can run a XUL application on a system with Firefox via 
/path/to/firefox --app /path/to/application.ini.


That also means that you could technically repurpose a Firefox 
distribution to serve as your application's distribution by replacing 
its application.ini and other application/branding files with your 
application's files. The experimental qbrt project 
 does this.


Note that these approaches aren't officially supported. However, the 
--app flag has been present in Firefox for a long time, and I'm not 
aware of any plans to remove it.


-myk

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

Re: Intent to ship: Changing default Japanese fonts to modern fonts

[ISHIKAWA,chiaki]

Thank you for the clarification.

The bit about MS Gothic reminds me why we seem to have rather classic 
feel to the monospace font web rendering, I suppose.


On 2017/08/24 11:45, Masayuki Nakano wrote:
Ah, yes, this change is only on Windows (only on Windows, we still use 
legacy Japanese fonts as default settings).
FYI: We still need to keep using legacy "MS Gothic" font for default 
Japanese monospace font since Windows doesn't have modern monospace font.


On 8/24/2017 7:47 AM, ISHIKAWA,chiaki wrote:

Hi,

I use firefox under Windows most of the time, and so it will be very 
nice.


But obviously this is only for Windows platform, and
does not affect linux or OSX versions. Correct?



On 2017/08/23 14:19, Masayuki Nakano wrote:

Hi,

We decided that we should change our default Japanese fonts from 
legacy "MS PGothic" (sans-serif) and "MS PMincho" (serif) which have 
bitmap glyph to modern "Meiryo" or "Yu Gothic" (sans-serif) and "Yu 
Mincho" (serif).


This has been enabled on Nightly and early Beta since 55 [1].

Then, I removed the |#ifdef EARLY_BETA_OR_EARLIER| in Nightly 
yesterday [2].  I.e., the new default settings are enabled on release 
build starting from 57.


I'd like to introduce some backgrounds:

"Meiryo" is installed on Vista or later (but not installed on Win10 
unless you add Japanese in system language settings). "Yu Gothic" and 
"Yu Mincho" is installed on Win8.1 or later.


Both Edge and Chrome already started to use "Meiryo" as their default 
Japanese fonts. So, using "Meiryo" improves the compatibility between 
browsers and just looks better and is easier to read than bitmap glyph.


One of the reason why we didn't use "Meiryo" as default fonts is, 
"Meiryo" has normal style glyph as italic style glyph. E.g., 
|abc| looks like |abc|, not |a/b/c|. The other browsers have 
this issue, but I see many users who complain about this issue. For 
solving this issue, we added a hack to ignore italic style family of 
"Meiryo" at loading fonts [3]. So, now, Gecko is the only one engine 
which supports italic style Japanese text with default fonts!


On the other hand, there are still some problems.

"Meiryo" has too big internal leading for supporting accent marks of 
Western languages. This causes increasing normal line height than 
other fonts. Additionally, Gecko's normal line height computation is 
not same as the other browsers. Therefore, this may cause 
compatibility issue with the other browsers. For example, our  
allows to scroll its content. Therefore, if user drags text in 
 vertically, the text may be scrolled [4].


If we could use "Yu Gothic" as Japanese default font, it'd be really 
nicer except compatibility with the other browsers because it has 
nicer glyph than "Meiryo" ("Meiryo" was designed for UI, not for 
document. Therefore, it was designed as easier to read even if the 
font size is small) and does not have too big leading like "Meiryo". 
However, there is a big problem. Text renderer of Windows has a bug. 
Text of "Yu Gothic" is rendered as too light [5]. So, the contrast 
between text and background color may not be enough for some users. 
Therefore, currently, we use "Yu Gothic" as a fallback font only when 
"Meiryo" isn't available.


Anyway, I believe that this makes 57 look nicer for Japanese users!

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=548311
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1354004
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1351332
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1378065
[5] https://bug548311.bmoattachments.org/attachment.cgi?id=8848439



___
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