Bug 1260651 will rename whole classes under editor/libeditor, so, when you need to touch in it, let me know before landing

[Masayuki Nakano]

Hi, folks,

I've written 60 patches for bug 1260651 in this two days. These patches 
conflict with any changes under editor/libeditor. So, if you need to 
touch under the directory, please let me know before writing a patch or 
landing a patch.


Ehsan, if you're busy to review for now, let me know. Smaug might be a 
good reviewer for that.


Thanks in advance.

--
Masayuki Nakano 
Manager, Internationalization, Mozilla Japan.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: MXR permanently offline, please transition to DXR

[Douglas Turner]

Philip,
Can you please file bugs.  There is no need to discuss your specific eye
strain issues or what DXR should or should not index on dev-platform.

Also, the point that people are making here is that MXR wasn't safe to run
and we are fixing that by decommissioning.  You're more than welcome to
deploy this old software but you're going to get shell pop'ed and have a
really bad day.  And, trust me, those days really bad days suck.

Thanks,
Doug Turner


On Fri, Jun 24, 2016 at 9:50 PM Philip Chee  wrote:

> On 24/06/2016 22:50, glob wrote:
> > Philip Chee wrote:
> >>
> >> I wonder what is necessary to set up an instance of MXR (for comm-*) on
> >> our own server (or vps). I would guess PERL, hg, and a Linux VM.
> >
> > mxr was shutdown due to some very serious security issues; i strongly
> > advise against standing up your own instance unless you first put a lot
> > of time against securing it.
> >
> > you'd be better served by deploying an alternative source browser.
>
> MXR uses black text (#00) on a white background (#FF).
> DXR uses grey goop that pretends to be text and gives me eye-strain.
>
> MXR gives me a choice of {mozilla|comm}-{central|aurora|beta|release|esrNN}
> Plus legacy repositories like mozilla-1.8 1.9 1.9.2 etc
>
> DXR only gives me mozilla-central.
>
> Phil
>
> --
> Philip Chee , 
> http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
> Guard us from the she-wolf and the wolf, and guard us from the thief,
> oh Night, and so be good for us to pass.
> ___
> 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

[Philip Chee]

On 24/06/2016 22:50, glob wrote:
> Philip Chee wrote:
>>
>> I wonder what is necessary to set up an instance of MXR (for comm-*) on
>> our own server (or vps). I would guess PERL, hg, and a Linux VM.
> 
> mxr was shutdown due to some very serious security issues; i strongly 
> advise against standing up your own instance unless you first put a lot 
> of time against securing it.
> 
> you'd be better served by deploying an alternative source browser.

MXR uses black text (#00) on a white background (#FF).
DXR uses grey goop that pretends to be text and gives me eye-strain.

MXR gives me a choice of {mozilla|comm}-{central|aurora|beta|release|esrNN}
Plus legacy repositories like mozilla-1.8 1.9 1.9.2 etc

DXR only gives me mozilla-central.

Phil

-- 
Philip Chee , 
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: WebRTC connections do not trigger content policies. Should they?

[Paul Ellenbogen]

I think you are right. I asked
 on the Easy List forum
and didn't get any compelling reason WebRTC could be blocked from
advertisers. Advertisers would be able to do what you describe to allow for
harder to block dynamic IPs. As you said elsewhere, advertisers probably
want to be in a 3rd party context in order to set cookies across domains.

On Sat, Jun 18, 2016 at 6:37 AM, Eric Rescorla  wrote:

> The priority of this proposed feature seems to depend rather a lot on
> whether enough
> advertisers are using WebRTC to deliver ads to make it worth some ad
> blocker being
> interest in adding such a blocker. Do we have any evidence on this front?
>
> It's worth noting that from a security and tracking perspective, ads
> delivered via this
> mechanism look a lot more like first party ads (they are in the origin of
> the main
> page and do not get cookies from the advertiser's origin). So, in that
> respect all
> you're really doing is making it possible for the advertiser to send the
> data directly
> to the user rather than tunnelling it through the publisher. That's
> potentially of some
> value, but perhaps not an enormous amount.
>
> As a thought experiment, consider an ad serving design in which publishers
> include
> ad content as they do now but instead of having it sourced from the
> advertiser's
> origin, they instead stand up ".publisher.example.com" and
> point
> it at the advertiser's IP addresses (via an A record to the advertiser's
> name never
> appears). This would have a similar cost/effort structure to using data
> channels and
> would similarly not be blocked by current domain-based ad blockers. What
> would our
> expectations be here?
>
> -Ekr
>
___
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?

[Douglas Turner]

I am a peer.  Feel free to file a bug against me to remove this port. It
served it's purpose. Anyone that wants to keep it alive can do it outside
of m-c (long live dvcs).



On Thu, Jun 23, 2016 at 12:35 PM Benjamin Smedberg 
wrote:

> 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: MXR permanently offline, please transition to DXR

[Mike Hoye]

On 2016-06-24 6:20 AM, Philip Chee wrote:


I wonder what is necessary to set up an instance of MXR (for comm-*) on
our own server (or vps). I would guess PERL, hg, and a Linux VM.
I've got the impression that comm-* has enough rocks to push up the 
legacy-stack hill already.


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

Re: MXR permanently offline, please transition to DXR

[glob]

Philip Chee wrote:


I wonder what is necessary to set up an instance of MXR (for comm-*) on
our own server (or vps). I would guess PERL, hg, and a Linux VM.


mxr was shutdown due to some very serious security issues; i strongly 
advise against standing up your own instance unless you first put a lot 
of time against securing it.


you'd be better served by deploying an alternative source browser.


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

Re: MXR permanently offline, please transition to DXR

[Philip Chee]

On 24/06/2016 09:41, Edmund Wong wrote:
> 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?

I wonder what is necessary to set up an instance of MXR (for comm-*) on
our own server (or vps). I would guess PERL, hg, and a Linux VM.

Phil

-- 
Philip Chee , 
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform