Re: Plan for Sunsetting MozReview

[Botond Ballo]

> Until this gets fixed, a workaround for closed bugs is to go to the bottom of 
> the bug, and look for https://hg.mozilla.org/mozilla-central/rev/... links.
> Not as pretty, and missing review context, but hopefully this should help 
> explore the changed code in most cases.

For bugs that aren't closed, or where you specifically want to look at
an older revision than the one that landed, you can also query the
review repo for all revisions associated with a bug:

https://hg.mozilla.org/mozreview/gecko/log?rev=

(assuming the bug number is present in the commit message).

Hope that helps!

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

Re: Plan for Sunsetting MozReview

[gsquelart]

(Disclaimer: I'm not from IT!)

Until this gets fixed, a workaround for closed bugs is to go to the bottom of 
the bug, and look for https://hg.mozilla.org/mozilla-central/rev/... links.
Not as pretty, and missing review context, but hopefully this should help 
explore the changed code in most cases.

Cheers,
Gerald

On Tuesday, August 28, 2018 at 8:17:24 AM UTC+10, Eric Shepherd (Sheppy) wrote:
> We've noticed that attachment links are no longer working because they're
> still trying to go to reviewboard, and there don't appear to be redirects.
> See for example this bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1211330. It has two
> attachments. Clicking either one of them gives you a hard-hat page instead
> of the changes.
> 
> Eric Shepherd
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Plan for Sunsetting MozReview

[Eric Shepherd (Sheppy)]

We've noticed that attachment links are no longer working because they're
still trying to go to reviewboard, and there don't appear to be redirects.
See for example this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1211330. It has two
attachments. Clicking either one of them gives you a hard-hat page instead
of the changes.


On Fri, Jul 27, 2018 at 1:30 PM Mark Côté  wrote:

> To follow up on my follow up, there were some good suggestions on
> dev-platform, so we're going to amend our plan somewhat.
>
> On August 20, we will remove public access to MozReview and move all the
> repositories on hg-reviewboard.mozilla.org to hg.mozilla.org (exact
> location TBD). We will create a simple redirection service that will map
> each of the following:
>
> * review-request diff to appropriate changeset in the review repo on
> hg.mozilla.org
> * review request to associated bug
> * review to the associated BMO comment
>
> Only diffs that have “stub attachments” will be redirected, which means
> the most recent diffs on review requests. This includes any abandoned or
> obsoleted diffs.
>
> This will ensure that all stub attachments redirect to diffs, and that any
> reviewboard.mozilla.org links in docs, browser histories, etc., will
> redirect to equivalent content. It was also preserve any unpublished
> commits that were part of a diff's history.
>
> There is no change to the update-only period from August 6 to August 20.
>
> Mark
>
>
> On Thu, Jul 26, 2018 at 2:37 PM, Mark Côté  wrote:
>
>> To follow up on some previous threads, here is the plan for deprecating,
>> archiving, and decommissioning MozReview.
>>
>> The MozReview shutdown deadline is approaching. Although enhanced
>> commit-series support is still in progress (see update below), MozReview
>> users should start familiarizing themselves with Phabricator now. We have a
>> guide specifically for MozReview users to ease the transition (which will
>> be updated when the commit-series work is finalized):
>> https://moz-conduit.readthedocs.io/en/latest/mozreview-migration-guide.html
>>
>> From August 6 to August 20, use of MozReview will be restricted to
>> updates to existing reviews. In other words, review cycles in progress will
>> be given until August 20 to be completed, but no new commit series will be
>> permitted.
>>
>> On August 20, we will remove public access to MozReview and archive
>> patches. Every landed, in-progress, and abandoned patch will be downloaded
>> from MozReview and stored in an S3 bucket. The “stub attachments” in
>> Bugzilla that currently redirect to MozReview will be updated to link to
>> the appropriate S3 bucket. Review flags and bug comments will be preserved.
>>
>> After archiving is complete and verified, the MozReview servers will be
>> decommissioned.
>>
>> We will also be writing a simple redirection service to map specific
>> MozReview reviews to associated BMO comments, review requests to associated
>> bugs, and review-request diffs to the appropriate S3 buckets. This service
>> will be up shortly after MozReview is decommissioned.
>>
>> We realize and apologize that this is a fairly short timeline; however,
>> the current location of the MozReview servers is in the process of being
>> shut down, and thus it is urgent that we decommission this service soon to
>> allow an orderly exit.
>>
>> As for enhanced support for series of commits in Phabricator, the new
>> command-line interface to submit, update, and apply series (bug 1471678) is
>> currently in review. The first release will support Mercurial only, but
>> git-cinnabar support will follow shortly (the code is designed with it in
>> mind). Work on series support in Lando (bug 1457525) is progressing; we
>> will be posting screenshots of the new UI shortly. It should be ready in
>> 2-3 weeks.
>>
>> Please note that we eventually plan to decommission Splinter as well;
>> however, we know we need some time to work out the kinks in Phabricator.
>> Splinter will remain operational near-term, but we ask everybody to
>> familiarize themselves with Phabricator and file bugs when things don't
>> work. *Please do not wait for Splinter EOL to try Phabricator; we need your
>> feedback before then in order to act on it.*
>>
>> Mark
>>
>>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>


-- 

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Scheduling code coverage builds on try

[Gregory Mierzwinski]

Hello,

As of now, we've completely disabled any code coverage builds (*-ccov or
*-jsdcov) from running on try when try syntax is used with the changes in
[1]. A change has also been made in [2] that now requires the use of the
`--full` argument with |mach try fuzzy --full| to be able to schedule any
code coverage tasks, making it bit more difficult for them to be selected.
This means that the command |mach try fuzzy --full| will be the only way to
schedule code coverage tasks from now on.

Greg

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1473048
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1397722
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Please don't use functions from ctype.h and strings.h

[Henri Sivonen]

I think it's worthwhile to have a lint, but regexps are likely to have
false positives, so using clang-tidy is probably better.

A bug is on file: https://bugzilla.mozilla.org/show_bug.cgi?id=1485588

On Mon, Aug 27, 2018 at 4:06 PM, Tom Ritter  wrote:
> Is this something worth making a lint over?  It's pretty easy to make
> regex-based lints, e.g.
>
> yml-only based lint:
> https://searchfox.org/mozilla-central/source/tools/lint/cpp-virtual-final.yml
>
> yml+python for slightly more complicated regexing:
> https://searchfox.org/mozilla-central/source/tools/lint/mingw-capitalization.yml
> https://searchfox.org/mozilla-central/source/tools/lint/cpp/mingw-capitalization.py
>
> -tom
>
> On Mon, Aug 27, 2018 at 7:04 AM, Henri Sivonen  wrote:
>>
>> Please don't use the functions from ctype.h and strings.h.
>>
>> See:
>> https://daniel.haxx.se/blog/2018/01/30/isalnum-is-not-my-friend/
>> https://daniel.haxx.se/blog/2008/10/15/strcasecmp-in-turkish/
>>
>> https://stackoverflow.com/questions/2898228/can-isdigit-legitimately-be-locale-dependent-in-c
>>
>> In addition to these being locale-sensitive, the functions from
>> ctype.h are defined to take (signed) int with the value space of
>> *unsigned* char or EOF and other argument values are Undefined
>> Behavior. Therefore, on platforms where char is signed, passing a char
>> sign-extends to int and invokes UB if the most-significant bit of the
>> char was set! Bug filed 15 years ago!
>> https://bugzilla.mozilla.org/show_bug.cgi?id=216952 (I'm not aware of
>> implementations doing anything surprising with this UB but there
>> exists precedent for *compiler* writers looking at the standard
>> *library* UB language and taking calls into standard library functions
>> as optimization-guiding assertions about the values of their
>> arguments, so better not risk it.)
>>
>> For isfoo(), please use mozilla::IsAsciiFoo() from mozilla/TextUtils.h.
>>
>> For tolower() and toupper(), please use ToLowerCaseASCII() and
>> ToUpperCaseASCII() from nsUnicharUtils.h
>>
>> For strcasecmp() and strncasecmp(), please use their nsCRT::-prefixed
>> versions from nsCRT.h.
>>
>> (Ideally, we should scrub these from vendored C code, too, since being
>> in third-party code doesn't really make the above problems go away.)
>>
>> --
>> Henri Sivonen
>> hsivo...@mozilla.com
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>
>



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

Re: Please don't use functions from ctype.h and strings.h

[Tom Ritter]

Is this something worth making a lint over?  It's pretty easy to make
regex-based lints, e.g.

yml-only based lint:
https://searchfox.org/mozilla-central/source/tools/lint/cpp-virtual-final.yml

yml+python for slightly more complicated regexing:
https://searchfox.org/mozilla-central/source/tools/lint/mingw-capitalization.yml
https://searchfox.org/mozilla-central/source/tools/lint/cpp/mingw-capitalization.py

-tom

On Mon, Aug 27, 2018 at 7:04 AM, Henri Sivonen  wrote:

> Please don't use the functions from ctype.h and strings.h.
>
> See:
> https://daniel.haxx.se/blog/2018/01/30/isalnum-is-not-my-friend/
> https://daniel.haxx.se/blog/2008/10/15/strcasecmp-in-turkish/
> https://stackoverflow.com/questions/2898228/can-isdigit-
> legitimately-be-locale-dependent-in-c
>
> In addition to these being locale-sensitive, the functions from
> ctype.h are defined to take (signed) int with the value space of
> *unsigned* char or EOF and other argument values are Undefined
> Behavior. Therefore, on platforms where char is signed, passing a char
> sign-extends to int and invokes UB if the most-significant bit of the
> char was set! Bug filed 15 years ago!
> https://bugzilla.mozilla.org/show_bug.cgi?id=216952 (I'm not aware of
> implementations doing anything surprising with this UB but there
> exists precedent for *compiler* writers looking at the standard
> *library* UB language and taking calls into standard library functions
> as optimization-guiding assertions about the values of their
> arguments, so better not risk it.)
>
> For isfoo(), please use mozilla::IsAsciiFoo() from mozilla/TextUtils.h.
>
> For tolower() and toupper(), please use ToLowerCaseASCII() and
> ToUpperCaseASCII() from nsUnicharUtils.h
>
> For strcasecmp() and strncasecmp(), please use their nsCRT::-prefixed
> versions from nsCRT.h.
>
> (Ideally, we should scrub these from vendored C code, too, since being
> in third-party code doesn't really make the above problems go away.)
>
> --
> Henri Sivonen
> hsivo...@mozilla.com
> ___
> 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

Please don't use functions from ctype.h and strings.h

[Henri Sivonen]

Please don't use the functions from ctype.h and strings.h.

See:
https://daniel.haxx.se/blog/2018/01/30/isalnum-is-not-my-friend/
https://daniel.haxx.se/blog/2008/10/15/strcasecmp-in-turkish/
https://stackoverflow.com/questions/2898228/can-isdigit-legitimately-be-locale-dependent-in-c

In addition to these being locale-sensitive, the functions from
ctype.h are defined to take (signed) int with the value space of
*unsigned* char or EOF and other argument values are Undefined
Behavior. Therefore, on platforms where char is signed, passing a char
sign-extends to int and invokes UB if the most-significant bit of the
char was set! Bug filed 15 years ago!
https://bugzilla.mozilla.org/show_bug.cgi?id=216952 (I'm not aware of
implementations doing anything surprising with this UB but there
exists precedent for *compiler* writers looking at the standard
*library* UB language and taking calls into standard library functions
as optimization-guiding assertions about the values of their
arguments, so better not risk it.)

For isfoo(), please use mozilla::IsAsciiFoo() from mozilla/TextUtils.h.

For tolower() and toupper(), please use ToLowerCaseASCII() and
ToUpperCaseASCII() from nsUnicharUtils.h

For strcasecmp() and strncasecmp(), please use their nsCRT::-prefixed
versions from nsCRT.h.

(Ideally, we should scrub these from vendored C code, too, since being
in third-party code doesn't really make the above problems go away.)

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

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

[Bogdan Maris]

Hello,

Here's the list of new issues found and filed by the Desktop Release QA team 
last two weeks.
Additional details on the team's priorities last week, as well as the plans for 
the current week are available at: https://tinyurl.com/yclje85s
Bugs logged by Desktop Release QA in the last 7 days

Firefox: Address Bar
NEW - https://bugzil.la/1484661 - CTRL+ENTER on @amazon and @google brings up 
login confirmation window

Firefox: Activity Streams: Newtab
NEW - https://bugzil.la/1484663 - Text cursor instead of pointer while hovering 
over @amazon and @google topsite text in new-tab page
NEW - https://bugzil.la/1484912 - Middle click on @search Top Site highlights 
the previously clicked one
NEW - https://bugzil.la/1485292 - Search suggestion dropdown panel overlength 
the search bar when resizing the browser
NEW - https://bugzil.la/1485294 - [Mac] Highlight color makes the selected text 
indiscernible on dark theme inside New Tab page
NEW - https://bugzil.la/1485379 - [Intermittent] Custom images are not set 
until Top Sites are refreshed
NEW - https://bugzil.la/1485563 - [mac] Hover state easily mistaken as keyboard 
selection in AS context menus
NEW - https://bugzil.la/1485586 - The Edit button (" ... ") is barely visible 
if Dark Theme is active
NEW - https://bugzil.la/1485607 - Dropdowns from activity stream should become 
dropups if not enough space bellow
NEW - https://bugzil.la/1485621 - Title for input form containers in newTab 
page could be shifted up by a few pixels from the rest of the content
NEW - https://bugzil.la/1485633 - Context menu is displayed wrong (on the right 
side) for the last Highlight from a row
NEW - https://bugzil.la/1485987 - Generated search shortcuts paste links after 
being copied instead of the string in newtab
NEW - https://bugzil.la/1485999 - The @ebay shortcut doesn't perform the search 
correctly on locale builds

Firefox: Enterprise Policies
NEW - https://bugzil.la/1485636 - The about:policies information is displayed 
overlapped after resizing the browser window

Firefox: Tabbed Browser
NEW - https://bugzil.la/1485700 - about:blank is differently displayed between 
homepage (new tab) and new windows

Firefox: Preferences
NEW - https://bugzil.la/1485893 - The text for an installed extension almost 
overlaps the "Disable Extension" button in about:preferences#home
NEW - https://bugzil.la/1485894 - [mac] Arrow icon displayed out of the content 
area inside the Set Home Page panel
NEW - https://bugzil.la/1485897 - [Linux] - Text in about:preferences page is 
truncated on shrinking browser


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

Regards,
Bogdan (:bogdan_maris)
Desktop Release QA

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