Re: MXR permanently offline, please transition to DXR

[Edmund Wong]

Ms2ger wrote:
> On 22/06/16 20:30, Lawrence Mandel wrote:
>> Mozilla Cross-Reference, better known as MXR (https://mxr.mozilla.org), was
>> taken offline on June 13, 2016, to investigate a potential security issue.
>> After careful review of the codebase, we have decided to accelerate the
>> planned transition from MXR to its more modern equivalent, DXR (
>> https://dxr.mozilla.org), instead of bringing MXR back online.
> 
> I wish the years of complaining about MXR had led to an equally useful
> replacement for it by now.
> 
> Sad to see it go.

Ditto.  It's been my mainstay for searching code... couldn't dxr have
a similar ui and does it have to default to mozilla-central?

Edmund

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

Re: MXR permanently offline, please transition to DXR

[Cameron Kaiser]

On 6/23/16 5:49 AM, Ms2ger wrote:

On 22/06/16 20:30, Lawrence Mandel wrote:

Mozilla Cross-Reference, better known as MXR (https://mxr.mozilla.org), was
taken offline on June 13, 2016, to investigate a potential security issue.
After careful review of the codebase, we have decided to accelerate the
planned transition from MXR to its more modern equivalent, DXR (
https://dxr.mozilla.org), instead of bringing MXR back online.


I wish the years of complaining about MXR had led to an equally useful
replacement for it by now.

Sad to see it go.


As am I. I got a lot of miles out of it, especially for searching 
historical source trees.


Cameron Kaiser
mxr? I dn't evn knw hr

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

Heads up on awesome change to socorro that will change crash stats...

[Milan Sreckovic]

The authors of the fix can explain in details what is going on, but since the 
users will experience (great, but new) results with currently processed crash 
reports, it was suggested I should mention it to a larger audience.

https://bugzilla.mozilla.org/show_bug.cgi?id=1274345 


This is now live, which means that the new reports coming in are going to skip 
the DLLs without symbols, which means that, for example, driver crashes will 
start getting grouped together, and we will see what’s actually going on.

It also means we will start seeing the driver crashes that were processed 
before this change start dropping in frequency - probably a good idea not to 
dismiss them as “this got fixed somehow”, but instead look to see if they are 
now subsumed by a new, more awesome bug.

As an example tracked here https://bugzilla.mozilla.org/show_bug.cgi?id=1267970 
 - the crash went from 
411th to 19th (in 47) once all the different driver versions were aggregated 
and the DLLs without symbols were ignored.

And, yes, chances are we will see some over-grouping, but the worst case 
scenario is that we look at a crash that looks important, and turns out not to 
be, or that we only fix it partially, and then discover the lurkers.  Either 
way, much better scenario than not noticing problems because they’re scattered. 
—
- Milan



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

Re: Why do we still need to include Qt widget in mozilla-central?

[Benjamin Smedberg]

I'm going to resurrect this old thread to ask: is anybody currently
triaging bugs the Core: Widget: Qt bugzilla component? I'm trying to find
owners for all of our active bugzilla components, and I'm not sure the
status of this.

I would support us removing the widget/qt code from the tree unless we have
clear ownership not only of reviewing patches, but the supporting
activities such as bug triage and some kind of continuous automation.

--BDS

On Sun, Apr 17, 2016 at 11:12 AM, Raine Mäkeläinen <
raine.makelai...@gmail.com> wrote:

> I think that in this context we are talking about mozilla/widget/qt/*
> components and yes we're using those in our Gecko build. We don't use
> QWidgets for Sailfish Browser. User interface of the Sailfish Browser is
> written with Qt QML.
>
> There is more info in the embedding wiki [1] and Dmitry's blog [2].
> Rendering pipeline has changed after Dmitry's blog post but otherwise quite
> close to the current state.
>
> [1]
> https://wiki.mozilla.org/Embedding/IPCLiteAPI
>
> [2]
> http://blog.idempotent.info/posts/whats-behind-sailfish-browser.html
>
> -Raine
>
> 2016-04-14 20:38 GMT+03:00 Henri Sivonen :
>
> > Added Raine Mäkeläinen, who has been committing to qtmozembed lately, to
> > CC.
> >
> > On Thu, Apr 14, 2016 at 1:51 AM, Jim Blandy  wrote:
> > > On Tue, Apr 12, 2016 at 4:27 AM, Henri Sivonen 
> > wrote:
> > >>
> > >> On Tue, Apr 12, 2016 at 7:45 AM, Masayuki Nakano <
> masay...@d-toybox.com
> > >
> > >> wrote:
> > >> > So, my question is, why do we still have Qt widget in
> mozilla-central?
> > >> > What
> > >> > the reason of keeping it in mozilla-central?
> > >>
> > >> My understanding is that
> > >> https://git.merproject.org/mer-core/qtmozembed/ still uses it. As we
> > >> are figuring out how to be more embeddable (see
> > >> https://medium.com/@david_bryant/embed-everything-9aeff6911da0 ),
> it's
> > >> probably a bad time to make life hard for an existing embedding
> > >> solution.
> > >
> > >
> > > This doesn't really answer the question. We can't have code in tree
> that
> > > isn't tested, and isn't used, and has nobody responsible for it.
> > >
> > > If someone is willing to fix it up and get it tested and included in
> the
> > > continuous integration process, then that's fine. But "someone might
> > want to
> > > use it in the future" can't possibly be a legit reason to keep
> > substantial
> > > bits of code in the tree.
> >
> > It looked to me like the code is being used *now*.
> >
> > Raine, does qtmozembed use the Qt widget code from mozilla-central?
> >
> > --
> > Henri Sivonen
> > hsivo...@hsivonen.fi
> > https://hsivonen.fi/
> >
> ___
> 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

Fwd: [TCW] Scheduled Tree Closing Maintenance Window 2016-06-25 06:00hrs PDT (1.5 Hours)

[Hal Wine]

NOTE: we do not expect any significant disruption from this activity, but a
few jobs may burn. Developers are responsible for sheriffing their own
jobs, and re-triggering as needed.

Thanks!
-- Forwarded message --
From: 
Date: Thu, Jun 23, 2016 at 11:09 AM
Subject: [TCW] Scheduled Tree Closing Maintenance Window 2016-06-25
06:00hrs PDT (1.5 Hours)
To: all-moco-m...@mozilla.com


Start Date/Time: 2016-06-25 06:00hrs PDT

End date/time: 2016-06-25 07:30hrs PDT

Impact to Users:

   - Unknown total impact to end-users due to recent increased adoption of
   server proxies.  Expect intermittent failures for all applications in
   SCL3/Neo-PHX1 that require outbound Internet connections to operate.

*TCW Tracking Bug: *https://bugzilla.mozilla.org/show_bug.cgi?id=1278976

*List of Work to be Completed:*

CHG0010443

- Bug 1278930  -
Patch datacenter proxies

   - Impact: Intermittent Internet connectivity failure for servers
   utilizing proxies being restarted.

CHG0010444
-
Bug 1278931  - Patch
releng DNS servers ns[12].private.releng.scl3

   - Impact: Intermittent DNS resolution failures while nameservers are
   restarted.



If you have questions about this issue, please email m...@mozilla.com or
visit #moc in IRC.  We appreciate your patience while we perform this
maintenance work.

Thank you,

Mozilla Operations Center


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

Re: MXR permanently offline, please transition to DXR

[smaug]

On 06/23/2016 03:49 PM, Ms2ger wrote:

On 22/06/16 20:30, Lawrence Mandel wrote:

Mozilla Cross-Reference, better known as MXR (https://mxr.mozilla.org), was
taken offline on June 13, 2016, to investigate a potential security issue.
After careful review of the codebase, we have decided to accelerate the
planned transition from MXR to its more modern equivalent, DXR (
https://dxr.mozilla.org), instead of bringing MXR back online.


I wish the years of complaining about MXR had led to an equally useful
replacement for it by now.


searchfox.org actual is a very good alternative now. It has good integration 
with blame and at least so far it has
always given me the results what I've been looking for. (with dxr one may get 
occasionally rather unexpected results).
Just need to get addons/release/beta/aurora trees to searchfox.



Sad to see it go.

Ms2ger



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

Re: PSA: Removing the Pointerlock permission UI

[Jet Villegas]

Yay! Thank you :-)

--Jet

On Thursday, June 23, 2016, Dale Harvey  wrote:

> In https://bugzilla.mozilla.org/show_bug.cgi?id=1273351 I am working on
> removing the pointerlock permissions UI, now instead of a doorhanger
> permission that the user needs to respond to before entering pointerlock,
> the pointer lock will be granted with a warning given to the user
> explaining how to exit, similiar to fullscreen and in alignment with
> chromes implementation.
>
> Thanks
> Dale
> ___
> 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: MXR permanently offline, please transition to DXR

[Ms2ger]

On 22/06/16 20:30, Lawrence Mandel wrote:
> Mozilla Cross-Reference, better known as MXR (https://mxr.mozilla.org), was
> taken offline on June 13, 2016, to investigate a potential security issue.
> After careful review of the codebase, we have decided to accelerate the
> planned transition from MXR to its more modern equivalent, DXR (
> https://dxr.mozilla.org), instead of bringing MXR back online.

I wish the years of complaining about MXR had led to an equally useful
replacement for it by now.

Sad to see it go.

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

Re: Notes about implementing DOM APIs in Rust

[Ms2ger]

On 22/06/16 19:05, Henri Sivonen wrote:
> We shouldn't expect to be able to use Servo's implementations of DOM
> APIs in a drop-in a manner in Gecko. Because Servo allocates Rust
> objects on the JavaScript heap, but Gecko doesn't allocate C++ objects
> on the JavaScript heap,

For the record, this is not true. The significant difference is that
Servo creates a reflector (JSObject) for any DOM object as soon as it is
created, and this reflector is responsible for the deallocation of the
DOM object. Gecko instead manages the DOM object through reference
counting, and only creates a reflector when JS code needs it.

> the memory management arrangements of the two
> engines are fundamentally different and, therefore, the same WebIDL
> bindings won't work.

... but your conclusion remains correct.

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

PSA: Removing the Pointerlock permission UI

[Dale Harvey]

In https://bugzilla.mozilla.org/show_bug.cgi?id=1273351 I am working on
removing the pointerlock permissions UI, now instead of a doorhanger
permission that the user needs to respond to before entering pointerlock,
the pointer lock will be granted with a warning given to the user
explaining how to exit, similiar to fullscreen and in alignment with
chromes implementation.

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

Re: Proposed W3C Charter: Web of Things Interest Group

[Martin Thomson]

On Thu, Jun 23, 2016 at 3:19 AM, Anne van Kesteren  wrote:
> We should just let them do their thing and do our thing elsewhere.

This seems like a reasonable plan.  Unless and until someone thinks
that a course correction is feasible, or decides that it's worth
trying.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Notes about implementing DOM APIs in Rust

[Henri Sivonen]

On Jun 23, 2016 1:33 AM, "Andrew McCreight"  wrote:
>
> On Wed, Jun 22, 2016 at 1:05 PM, Henri Sivonen 
wrote:
>
> > Now that I'm looking at the hand-written notes that I made in the
> > meeting, I notice that the above paragraph fails to say how the
> > AddRef, Release and associated cycle collection-related calls are
> > routed from C++ to Rust or from Rust to C++. There was some talk about
> > vtable hacks, but my recollection is that those got rejected along
> > with XPCOM. So as far as I can tell, we are left with the meeting not
> > concluding how exactly these calls across the language boundary.
> >
>
> C++ CCed objects don't even all use COM. Maybe the existing
non-nsISupports
> CC infrastructure could be used for Rust objects. If that doesn't work,
> adding explicit support for Rust objects to the CC, like we have for JS,
> doesn't seem like it would be too difficult. The CC used to nominally
> support arbitrary languages.

Non-nsISupports cycle-collected objects were brought up as what we should
do in a way that avoids XPCOM. AFAICT, in this case, the methods need not
be virtual, so if we wanted to use a vtable-based solution for
cross-language calls, we'd need to make stuff virtual because of the
cross-language call mechanism.

In the absence of cross-language inlining (LLVM on both sides), which I'm
told is not about to happen on Windows, the trickery with "this" to make
FFI look C++ish to the C++ caller should inline into a plain function call,
which should be preferable to a virtual call. (If we ever get
cross-language inlining with clang and rustc, the inlining opportunity
would be even better.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform