Re: Intent to unship: HTML microdata API

[smaug]

On 05/19/2016 08:55 PM, Boris Zbarsky wrote:

Summary: The HTML Microdata API was removed from the spec due to lack of 
implementor interest.  See
.  Our implementation of 
it breaks some pages (due to the itemId attributes it adds) and is a
bunch of code.  I would like to remove it.


yes please. Thanks.


-Olli




Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=909633

Target release: 49

I believe I've removed all our in-browser dependencies on this stuff.  I 
haven't really checked addons because unfortunately the property names this
thing uses (e.g. "properties", "itemId") are way too common.  :(

-Boris




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

Re: What is "Process Type = content" in "mozilla crash reports"?

[Dirkjan Ochtman]

On Thu, May 19, 2016 at 11:28 PM, Tobias B. Besemer
 wrote:
> https://en.wikipedia.org/wiki/Streaming_SIMD_Extensions
> https://en.wikipedia.org/wiki/SSE2

Hi Tobias,

I applaud your enthusiasm in wanting to contribute to this effort.
However, in doing so, you've sent 8 messages in the past 16 hours, 6
of which were responding to other emails you yourself sent. Please
consider waiting a little longer and doing more research before you
send a message; dev-platform is a widely read mailing list, so each
email you sent takes significant attention, in the aggregate, to
process.

Thanks for taking this into account in the future,

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

Re: pushPrefEnv/popPrefEnv/flushPrefEnv now return Promises

[Ted Mielczarek]

On Thu, May 19, 2016, at 07:09 PM, Matthew N. wrote:
> Hello,
> 
> One of the reasons developers have been avoiding pushPrefEnv compared to 
> the synchronous set*Pref (with a registerCleanupFunction) is because 
> pushPrefEnv required using a callback function to wait for the 
> preference change before moving on in the test file. This can make the 
> test flow more complicated (especially when using add_task) and 
> therefore harder to follow.
> 
> Bug 1197310[1] made pushPrefEnv/popPrefEnv/flushPrefEnv return a promise 
> which resolves when the callbacks would have been called so now you can 
> simply write test code like so:
> 
> add_task(function* setup() {
>yield SpecialPowers.pushPrefEnv({"set": [["signon.debug", true]]});
>…
> })

This is a really great improvement, thanks!

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

Re: Considering dropping Talos support for Linux32

[Mike Hommey]

On Thu, Sep 24, 2015 at 06:40:08PM -0700, jma...@mozilla.com wrote:
> Our infrastructure at Mozilla does a great job of supporting all the
> jobs we need to run jobs for the thousands of pushes we do each month.
> Currently Talos runs on real hardware (and we have no plans to change
> that), but it does mean that we have a limited pool of available
> machines.  Right now this isn't a problem for Linux 32 or 64 since we
> don't run any other jobs on those platforms.
> 
> The problem we do have is on OSX and Windows, and in the last 2 weeks
> we have had a big problem with backlog on Windows.  The main reason we
> have a problem on OSX and Windows is because we run all the unit tests
> on there as well.  Granted we have a larger pool of machines, but we
> run a considerably larger volume of tests on there.
> 
> Trying to be smart about what we are doing, bug 1204920 [1] was filed
> to look into what would happen if we stopped running Talos on Linux32.
> We would still have OSX, Windows, and Linux64 support and from looking
> at all the data for the last 90 days, there are very few minor
> differences between 32 and 64 when it comes to catching regressions.
> 
> After looking into this, we realized that we could reimage the linux32
> machines as windows machines- this would then solve our backlog and
> give us some breathing room on capacity until we find other ways to
> reduce the load or make a more formal decision to increase the machine
> pool.
> 
> Sadly there are really no plans to formally add back Linux32 support.
> What does Linux32 give us that Linux64 doesn't when it comes to Talos
> results?  I am looking at this from a narrow lens, quite possibly
> someone else has ideas of what might be more useful.  Overall we are
> serious about doing this, but want to do it knowing more so at what
> cost.
> 
> Thanks for reading and fixing Performance regressions when they show
> up in your patches!

And here we are, 8 months later, deciding to compile linux32 builds with
SSE2, and no way to know what impact that has on performance...

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

Re: Considering dropping Talos support for Linux32

[joel maher]

we have 32 bit windows builds, are there specific concerns you have about
the perf impact of SSE2 and linux32 builds?

On Fri, May 20, 2016 at 7:14 AM, Mike Hommey  wrote:

> On Thu, Sep 24, 2015 at 06:40:08PM -0700, jma...@mozilla.com wrote:
> > Our infrastructure at Mozilla does a great job of supporting all the
> > jobs we need to run jobs for the thousands of pushes we do each month.
> > Currently Talos runs on real hardware (and we have no plans to change
> > that), but it does mean that we have a limited pool of available
> > machines.  Right now this isn't a problem for Linux 32 or 64 since we
> > don't run any other jobs on those platforms.
> >
> > The problem we do have is on OSX and Windows, and in the last 2 weeks
> > we have had a big problem with backlog on Windows.  The main reason we
> > have a problem on OSX and Windows is because we run all the unit tests
> > on there as well.  Granted we have a larger pool of machines, but we
> > run a considerably larger volume of tests on there.
> >
> > Trying to be smart about what we are doing, bug 1204920 [1] was filed
> > to look into what would happen if we stopped running Talos on Linux32.
> > We would still have OSX, Windows, and Linux64 support and from looking
> > at all the data for the last 90 days, there are very few minor
> > differences between 32 and 64 when it comes to catching regressions.
> >
> > After looking into this, we realized that we could reimage the linux32
> > machines as windows machines- this would then solve our backlog and
> > give us some breathing room on capacity until we find other ways to
> > reduce the load or make a more formal decision to increase the machine
> > pool.
> >
> > Sadly there are really no plans to formally add back Linux32 support.
> > What does Linux32 give us that Linux64 doesn't when it comes to Talos
> > results?  I am looking at this from a narrow lens, quite possibly
> > someone else has ideas of what might be more useful.  Overall we are
> > serious about doing this, but want to do it knowing more so at what
> > cost.
> >
> > Thanks for reading and fixing Performance regressions when they show
> > up in your patches!
>
> And here we are, 8 months later, deciding to compile linux32 builds with
> SSE2, and no way to know what impact that has on performance...
>
> Mike
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: IPCStream landed in mozilla-central

[Honza Bambas]

On 5/19/2016 17:04, Ben Kelly wrote:

Hi all,

FYI, I've landed a new IPDL type in bug 1093357 called IPCStream.  This is
intended to make it easier to serialize nsIInputStreams across IPC.

In short, IPCStream:

1) Supports our existing serializable nsInputStreams.
2) Also automatically handles send file descriptors using the
PFileDescriptorSet actor
3) Supports async pipe streams using a new PSendStream actor from
*child-to-parent*.  I have plans to add support for parent-to-child, but I
don't have a consumer yet


And I do! :)  Actually any parent necko channel, mainly HTTP, which 
sends data to the child process.  We also have bug 1110596 which 
complains about too much memory copying in that code.

Could your IPCStream be used for that?

-hb-

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

Re: Considering dropping Talos support for Linux32

[Mike Hommey]

On Fri, May 20, 2016 at 07:33:47AM -0400, joel maher wrote:
> we have 32 bit windows builds, are there specific concerns you have about
> the perf impact of SSE2 and linux32 builds?

GCC is not MSVC. They don't do the same kinds of optimizations (in fact,
MSVC happily uses both x87 and SSE when enabling SSE, GCC is supposed to
not use x87). One would expect improvements, but it could as well be 0.1%
or 10%, we wouldn't know unless we measure it...

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

Re: Tier-1 for Linux 64 Debug builds in TaskCluster on March 14 (and more!)

[Amy Rich]

On 19 May 2016, at 18:16, Selena Deckelmann wrote:

Closing out this thread - we made Linux 64 Debug builds Tier 1 
mid-April,

and last week we turned off the related buildbot jobs.


This is a fantastic, and incredibly important, milestone! 
Congratulations to everyone who's put so much work into this. I'm 
eagerly anticipating the long list of improvements we'll experience as 
we migrate our other platforms off of our legacy buildbot system.

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

Re: Updating 32-bit Windows users to 64-bit Windows builds?

[Tobias B. Besemer]

Am Freitag, 20. Mai 2016 01:48:24 UTC+2 schrieb Robert Strong:
> On Thu, May 19, 2016 at 3:18 PM, Tobias B. Besemer wrote:
> 
> > Am Freitag, 13. Mai 2016 22:41:01 UTC+2 schrieb Benjamin Smedberg:
> > > We have considered this, but in the grand rollout plans for 64-bit
> > Firefox
> > > it's low on the list. We're still dealing with Flash
> > sandboxing/functional
> > > regressions as a blocker for wider rollout, and the next step is probably
> > > to progressively roll out win64 to new users before we consider anything
> > > for existing users.
> > >
> > > This will be much easier now that we have widevine and are dropping
> > > npapi/silverlight, but addon compat is also a concern and we wanted to
> > > partly wait for webextensions before pushing more on this.
> > >
> > > --BDS
> >
> > Sounds like a plan for me!
> > Maybe there can be a ship of a installer that include 32bit & 64bit?
> > Or at least have one web-installer for both versions?
> > Also giving the user the change to make a easy upgrade from 32bit to 64bit
> > with the offline-installer would be nice and a good test-drive for a future
> > auto-update...
> >
> The installer does not equal auto-update. Two separate things entirely.
> Download size for a combined installer is not something we want to do to
> people on slow network connection but the auto selection via the stub
> installer is planned though no completion date yet due to other work having
> priority.

The idea was to test the upgrade from 32bit to 64bit first with the offline 
installer because it should effect less people and would be maybe a good test 
for all the routines/logic behind it like e.g. uninstall something, moving 
files, or something like this...

If not to much work, I would prefer to have one 32bit/64bit-installer for 
people who don't know the difference... (as default download.)
Single Just-32bit/64bit-installer can persist for people who know for what they 
have to looking for... (AFAICR other project did/do the same.) (At least with 
just-English and multi-lang installers...)

As I didn't knew how Mozilla will handle the switch... if - like by IE - there 
will be 32bit/64bit parallel, or like Chrome do it, just one version... I 
installed from each channel both version on my system and created a bunch of 
icons for it, because the version overwrite ATM the icons from each other...
I guess that a lot of people have the almost same scenario (both versions), but 
by mistake and don't realize it!
So a routine (first in offline installer) in the 64bit version that check if a 
(old) 32bit version exist too on the system and when, then de-install it while 
install/update the 64bit version would be (IMHO) nice.
(Can test this and make QA.)

Also I would like to see a error msg in future (or at least a big warning) if a 
user try to use the 32bit installer on a 64bit system.

AFAIK there is also no MozillaMaintenanceService as 64bit now...

...and the MozillaMaintenanceService should also block to install a 32bit 
version on a 64bit Win (even normally no-one use this installer manual) and 
uninstall 32bit if 64bit gets installed or updated.

A long open wish from me (and I guess others, too) would be to see in future a 
multi-lang web-installer. Should also make things easier...
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: What is "Process Type = content" in "mozilla crash reports"?

[Tobias B. Besemer]

Am Freitag, 20. Mai 2016 11:08:16 UTC+2 schrieb Dirkjan Ochtman:
> On Thu, May 19, 2016 at 11:28 PM, Tobias B. Besemer wrote:
> > https://en.wikipedia.org/wiki/Streaming_SIMD_Extensions
> > https://en.wikipedia.org/wiki/SSE2
> 
> Hi Tobias,
> 
> I applaud your enthusiasm in wanting to contribute to this effort.
> However, in doing so, you've sent 8 messages in the past 16 hours, 6
> of which were responding to other emails you yourself sent. Please
> consider waiting a little longer and doing more research before you
> send a message; dev-platform is a widely read mailing list, so each
> email you sent takes significant attention, in the aggregate, to
> process.
> 
> Thanks for taking this into account in the future,
> 
> Dirkjan

Normally I'm f*cking fast and do a lot more then others each day...
...also there are some rumors that I'm very intelligent and very creative what 
should be the reason that I thinking all the time about a lot of problems and 
ideas and then have a lot of creative ideas and solution in a short time...
This is normally the reason why I always (in each project, group, bug reporter, 
etc.) have much more things posted/open/write/etc. then others...
But if you think I work to much and it looks bad if more 
information/feedback/ideas/etc. come from me, then from others, then I will try 
to reduce the work I send into the project. ^^
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to drop TSF (Text Services Framework) support on WinXP and WinServer 2003

[Masayuki Nakano]

Done. Will be in 49.

On 2015/09/17 18:40, Masayuki Nakano wrote:

Summary: Drop TSF support only from WinXP and WinServer 2003.

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

Platforms: Windows XP, Windows Server 2003 and Windows Server 2003 R2

Estimated or target release: Gecko 44

Background:

I've already given up to support TSF on WinXP and WinServer 2003 since
the TSF on them are much immature and Natural Input which is Japanese
IME bundled on WinXP behaves too much complicated but few users were
used. Starting Gecko 41, TSF is enabled in default settings only on
Vista or later. For enabling TSF on WinXP or WinServer2k3, user needs to
change "intl.tsf.force_enable" to true from about:config.

Dropping this feature from WinXP will cause inconvenience to WinXP
Tablet users. But I think that such users were already updated their
devices to Android Tablet, iPad or newer Windows Tablet. So, it must not
be worthwhile to support limited support of TSF on legacy Windows.


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

Re: Redesigning the docshell/loadgroup/document interaction

[Ben Kelly]

On Fri, May 20, 2016 at 10:56 AM, Boris Zbarsky  wrote:

> Thoughts?  Any obvious problems with this plan?
>

We have the concept of network requests made from workers not associated
with a single document.  For example, SharedWorker attached to multiple
documents or a ServiceWorker servicing a push event.  In theory we want the
same load grouping behavior to abort requests if those workers terminate,
etc.

If we are refactoring things, can we include that concept as well?

Thanks.

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

Redesigning the docshell/loadgroup/document interaction

[Boris Zbarsky]

Background: We have a problem right now where the thing representing a 
"collection of loads" (a loadgroup) is attached to a docshell, not an 
individual document.  This causes issues like loads started from unload 
events being blamed on the new page and whatnot, though it's possible 
that loadinfo will help with some of those.


Proposal: We already have a concept of "document loadgroup"; right now 
it's just the one for the docshell the document is in.  I'm proposing 
that we make it a separate loadgroup, whose parent is the docshell 
loadgroup.  That is, as you navigate a docshell, each document will get 
its own loadgroup, all of these will be contained in the docshell's 
loadgroup, and subresources loaded for each document will be placed in 
the _document_'s loadgroup.


There is one conceptual problem here, which is where to put the document 
request itself.  I think there are two options:


1)  Put it in the docshell loadgroup.  This is probably the simplest 
thing to do, but it does have one significant drawback: it means onload 
handling has to either stay in the docshell loadgroup or needs hacks to 
keep track of the document request if it's moved to the document 
loadgroup, since the document request itself is not in the document 
loadgroup.


2)  Create the loadgroup when we're starting the document request.  The 
channel would just keep it alive while it's active; if we end up 
creating a document, the document can grab it from the channel and store 
it.  This might just work out OK.  It will require a bit more up-front 
work to handle onload correctly.


In both cases, we will likely need to think a bit about the various 
notification-firing docloader does (web progress listeners, basically) 
and how to keep that working reasonably.


I do think we want to keep the docshell-level loadgroup, so we can do 
things like cancel everything for all documents when the docshell is 
torn down.  Not that there should be much in the way of loads for 
non-active documents, but I'm not _that_ confident in this.


I believe this setup can be implemented somewhat incrementally, in that 
we can land an initial change and then start simplifying various stuff 
separately...


Thoughts?  Any obvious problems with this plan?

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

Re: How should I measure responsiveness?

[Jim Mathies]

> *   We don't have a "responsiveness index", but several people have
> found INPUT_EVENT_RESPONSE_MS useful.

INPUT_EVENT_RESPONSE_MS should be of pretty good use although you'll have to 
figure out how to measure for a short period of time after the dialog is 
displayed.

In non-e10s this should detect browser main thread jank if the slow script stop 
feature had the desired affect. In e10s you'll want to look at the same metric 
for the main thread in the content process since the browser main thread isn't 
impacted by content script.

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

Re: FF49a1: Page load of jumping points doesn't work like it should in Wikipedia

[Gijs Kruitbosch]

On 20/05/2016 16:11, Tobias B. Besemer wrote:

Plz open e.g. this URL:
https://en.wikipedia.org/wiki/Microsoft_Windows#Alternative_implementations

FF49a1 loads the page, jumps to "Alternative implementations", stays there for 
1-2 sec and then go ~1 screen-high (page) down.

Can someone very this bug?


The same thing happens in Chrome, so it seems like it's more likely to 
be an issue with Wikipedia.


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

Re: IPCStream landed in mozilla-central

[Ben Kelly]

On Fri, May 20, 2016 at 7:37 AM, Honza Bambas  wrote:

> And I do! :)  Actually any parent necko channel, mainly HTTP, which sends
> data to the child process.  We also have bug 1110596 which complains about
> too much memory copying in that code.
> Could your IPCStream be used for that?
>

Yes, I think that could work in general.

I think the main issue would be compat with existing nsIStreamListeners.
These listeners might be written such that they expect the nsIInputStream
passed in OnDataAvailable() to return their entire length from a single
Available() call.  This will not be true for a streamed pipe.

I'll try to get some patches ready to test with in the next couple weeks
and we can see.  Worst case we could do the accumulation into a string in
the child process to avoid spiking memory in the parent process.

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

Re: Tier-1 for Linux 64 Debug builds in TaskCluster on March 14 (and more!)

[Armen Zambrano G.]

On 2016-05-19 08:29 PM, Mike Hommey wrote:

On Thu, May 19, 2016 at 07:20:30PM -0500, J. Ryan Stinnett wrote:

On Thu, May 19, 2016 at 6:24 PM, Xidorn Quan  wrote:

2. I cannot retrigger any TC task.

This is pretty annoying when I was debugging intermittent issues. Hopefully
they could get fix before we migrate all Linux builds to TaskCluster,
otherwise we will lose the ability to debug certain kinds of bugs with
Linux builds.


Other people have also mentioned that they can't retrigger these TC
tasks, so this part sounds accurate. Bug 1274176 was filed recently
about this. I hope it will be prioritized, I agree it's frustrating
when working on intermittents.


It's also not possible to *trigger* new TC jobs on treeherder ; like,
pushing with no try syntax and filling what you want with "Add new
jobs". Or using "Add new job" after realizing you forgot a job in your
try syntax.

Mike



martianwars is working on it:
https://bugzilla.mozilla.org/show_bug.cgi?id=1254325

I believe we should have it by the end of June.

--
Zambrano Gasparnian, Armen
Automation & Tools Engineer
http://armenzg.blogspot.ca
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: pushPrefEnv/popPrefEnv/flushPrefEnv now return Promises

[Mike Conley]

This is great, thank you!

On 19/05/2016 7:09 PM, Matthew N. wrote:
> Hello,
> 
> One of the reasons developers have been avoiding pushPrefEnv compared to
> the synchronous set*Pref (with a registerCleanupFunction) is because
> pushPrefEnv required using a callback function to wait for the
> preference change before moving on in the test file. This can make the
> test flow more complicated (especially when using add_task) and
> therefore harder to follow.
> 
> Bug 1197310[1] made pushPrefEnv/popPrefEnv/flushPrefEnv return a promise
> which resolves when the callbacks would have been called so now you can
> simply write test code like so:
> 
> add_task(function* setup() {
>   yield SpecialPowers.pushPrefEnv({"set": [["signon.debug", true]]});
>   …
> })
> 
> As a reminder, the nice thing about pushPrefEnv is that the pref changes
> are reverted at the end of the test file which avoids them leaking into
> other tests unintentionally.
> 
> There are various places in the tree which wrote their own Promise
> wrappers for pushPrefEnv so feel free to file follow-up bugs blocking
> bug 1197310 to remove them.
> 
> Cheers,
> Matthew N. (:MattN)
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1197310
> 
> P.S. For those of you who didn't hear (since there was no announcement),
> you can use add_task in mochitest-plain and mochitest-chrome thanks to
> bug 1187701 if you load …/tests/SimpleTest/SpawnTask.js.
> ___
> 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: Tier-1 for Linux 64 Debug builds in TaskCluster on March 14 (and more!)

[Nathan Froyd]

On Fri, May 20, 2016 at 11:18 AM, Armen Zambrano G.  wrote:
> On 2016-05-19 08:29 PM, Mike Hommey wrote:
>> It's also not possible to *trigger* new TC jobs on treeherder ; like,
>> pushing with no try syntax and filling what you want with "Add new
>> jobs". Or using "Add new job" after realizing you forgot a job in your
>> try syntax.
>
> martianwars is working on it:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1254325
>
> I believe we should have it by the end of June.

Why are we moving to a new system when it's lacking user-facing
functionality that the old system had (T pushes on try comes to mind
also, but I believe that's been fixed...perhaps there are others,
too)?  I can believe taskcluster-based jobs bring a whole host of
benefits (having things in-tree seems fantastic, for one), but it's
hard to understand the enthusiasm for pushing forward when we have
useful features disappearing.

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

Re: Redesigning the docshell/loadgroup/document interaction

[smaug]

On 05/20/2016 05:56 PM, Boris Zbarsky wrote:

Background: We have a problem right now where the thing representing a "collection 
of loads" (a loadgroup) is attached to a docshell, not an
individual document.  This causes issues like loads started from unload events 
being blamed on the new page and whatnot, though it's possible that
loadinfo will help with some of those.

Proposal: We already have a concept of "document loadgroup"; right now it's 
just the one for the docshell the document is in.  I'm proposing that we
make it a separate loadgroup, whose parent is the docshell loadgroup.  That is, 
as you navigate a docshell, each document will get its own loadgroup,
all of these will be contained in the docshell's loadgroup, and subresources 
loaded for each document will be placed in the _document_'s loadgroup.

There is one conceptual problem here, which is where to put the document 
request itself.  I think there are two options:

1)  Put it in the docshell loadgroup.  This is probably the simplest thing to 
do, but it does have one significant drawback: it means onload handling
has to either stay in the docshell loadgroup or needs hacks to keep track of 
the document request if it's moved to the document loadgroup, since the
document request itself is not in the document loadgroup.

2)  Create the loadgroup when we're starting the document request.  The channel 
would just keep it alive while it's active; if we end up creating a
document, the document can grab it from the channel and store it.  This might 
just work out OK.  It will require a bit more up-front work to handle
onload correctly.

In both cases, we will likely need to think a bit about the various 
notification-firing docloader does (web progress listeners, basically) and how 
to
keep that working reasonably.

I do think we want to keep the docshell-level loadgroup, so we can do things 
like cancel everything for all documents when the docshell is torn down.
Not that there should be much in the way of loads for non-active documents, but 
I'm not _that_ confident in this.

I believe this setup can be implemented somewhat incrementally, in that we can 
land an initial change and then start simplifying various stuff
separately...

Thoughts?  Any obvious problems with this plan?

-Boris


Sounds good.

(1) vs (2) isn't quite clear to me though. Do you mean with (2) that docshell 
wouldn't have any loagroup, but a channel?
But then you say there would be docshell-level loadgroup... so doesn't that 
mean that document's loadgroup would be in it, so (1).


I assume we'd reuse loadgroup in case same inner window is used for many 
documents  (initial about:blank), right?


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

Re: FF49a1: Page load of jumping points doesn't work like it should in Wikipedia

[Adam Roach]

On 5/20/16 10:13, Gijs Kruitbosch wrote:

On 20/05/2016 16:11, Tobias B. Besemer wrote:

Plz open e.g. this URL:
https://en.wikipedia.org/wiki/Microsoft_Windows#Alternative_implementations 



FF49a1 loads the page, jumps to "Alternative implementations", stays 
there for 1-2 sec and then go ~1 screen-high (page) down.


Can someone very this bug?


The same thing happens in Chrome, so it seems like it's more likely to 
be an issue with Wikipedia. 


The fact that turning JavaScript off prevents this behavior would 
certainly seem to support that supposition.


--
Adam Roach
Principal Platform Engineer
Office of the CTO
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Win8 tests disabled by default on Try

[Chris AtLee]

We've been having a lot of problems with capacity for our Windows test
pools, with Windows 8 being particularly bad.

Today we disabled running Windows 8 64-bit tests by default on Try. If you
do really need Windows 8 tests for your try pushes, you can add try syntax
like this to enable: "try: -b o -p win64 -u mochitests[Windows 8]"

Treeherder's "Add new jobs" feature is also a great way to select
additional tests for your try push.

Please be mindful of our limited hardware capacity when choosing which
tests you need. We do publish a report of top pushers to try:
https://secure.pub.build.mozilla.org/builddata/reports/reportor/daily/highscores/highscores.html

We have been working on migrating as many tests as possible to AWS. So far
we have migrated many Windows 7 test suites over, but none of the Windows 8
suites have been migrated yet. Our plan is to focus instead on providing
Windows 10 testing in AWS, and then disable the Win8 tests once those are
ready.

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

Re: Redesigning the docshell/loadgroup/document interaction

[Boris Zbarsky]

On 5/20/16 11:04 AM, Ben Kelly wrote:

We have the concept of network requests made from workers not associated
with a single document.  For example, SharedWorker attached to multiple
documents or a ServiceWorker servicing a push event.  In theory we want the
same load grouping behavior to abort requests if those workers terminate,
etc.

If we are refactoring things, can we include that concept as well?


Hmm.  So the idea here is that each _worker_ has a group of requests 
associated with it, right?


That seems somewhat orthogonal to how we handle documents, at first 
blush, and seems like we can just do it: associate a loadgroup on the 
main thread with each worker.


-Boris

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

Re: Redesigning the docshell/loadgroup/document interaction

[Boris Zbarsky]

On 5/20/16 11:28 AM, smaug wrote:

(1) vs (2) isn't quite clear to me though. Do you mean with (2) that
docshell wouldn't have any loagroup, but a channel?


No.  I mean that the docshell would have a loadgroup.  When you navigate 
a docshell it would create the new channel, create a _new_ loadgroup, 
put the channel in the new loadgroup, put the new loadgroup in the 
docshell loadgroup.


If we end up creating a document from the channel, that document would 
grab the channel's loadgroup and use it as its own loadgroup.



But then you say there would be docshell-level loadgroup... so doesn't
that mean that document's loadgroup would be in it, so (1).


In both proposals the document's loadgroup is in the docshell's 
loadgroup.  The only difference is which loadgroup the document channel 
itself lives in.



I assume we'd reuse loadgroup in case same inner window is used for many
documents  (initial about:blank), right?


Yeah, this part could be complicated.  :(  Especially if we want to put 
the document channel in the document loadgroup: we'd have to move it in 
the reuse case or something.


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

Re: FF49a1: Page load of jumping points doesn't work like it should in Wikipedia

[Kartikaya Gupta]

Note that this might get fixed in chrome with their new "scroll
anchoring" feature -
https://developers.google.com/web/updates/2016/04/scroll-anchoring?hl=en

kats

On Fri, May 20, 2016 at 12:15 PM, Adam Roach  wrote:
> On 5/20/16 10:13, Gijs Kruitbosch wrote:
>>
>> On 20/05/2016 16:11, Tobias B. Besemer wrote:
>>>
>>> Plz open e.g. this URL:
>>>
>>> https://en.wikipedia.org/wiki/Microsoft_Windows#Alternative_implementations
>>>
>>> FF49a1 loads the page, jumps to "Alternative implementations", stays
>>> there for 1-2 sec and then go ~1 screen-high (page) down.
>>>
>>> Can someone very this bug?
>>
>>
>> The same thing happens in Chrome, so it seems like it's more likely to be
>> an issue with Wikipedia.
>
>
> The fact that turning JavaScript off prevents this behavior would certainly
> seem to support that supposition.
>
> --
> Adam Roach
> Principal Platform Engineer
> Office of the CTO
>
> ___
> 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: Tier-1 for Linux 64 Debug builds in TaskCluster on March 14 (and more!)

[Dustin Mitchell]

> BTW, starting yesterday, there was a "TaskClusterRobot" comment on my m-i
> push on GitHub with message "TaskCluster: @upsuper does not have permission
> to trigger tasks." [1][2]

This was due to an unfortunate interaction of the mirroring of gecko
to github, and the taskcluster-github component, which tried to run
it.  We've since fixed tc-github to ignore github pushes without any
github-specific configuration, so this is no longer an issue.

Please do file bugs for any remaining issues -- comments are easily
missed or forgotten on a mailing list.

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

Re: Tier-1 for Linux 64 Debug builds in TaskCluster on March 14 (and more!)

[Lawrence Mandel]

On Fri, May 20, 2016 at 11:27 AM, Nathan Froyd  wrote:

> On Fri, May 20, 2016 at 11:18 AM, Armen Zambrano G. 
> wrote:
> > On 2016-05-19 08:29 PM, Mike Hommey wrote:
> >> It's also not possible to *trigger* new TC jobs on treeherder ; like,
> >> pushing with no try syntax and filling what you want with "Add new
> >> jobs". Or using "Add new job" after realizing you forgot a job in your
> >> try syntax.
> >
> > martianwars is working on it:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1254325
> >
> > I believe we should have it by the end of June.
>
> Why are we moving to a new system when it's lacking user-facing
> functionality that the old system had (T pushes on try comes to mind
> also, but I believe that's been fixed...perhaps there are others,
> too)?  I can believe taskcluster-based jobs bring a whole host of
> benefits (having things in-tree seems fantastic, for one), but it's
> hard to understand the enthusiasm for pushing forward when we have
> useful features disappearing.
>
>
There will be some pain with this port and we're going to break some things
unintentionally and possibly some thing intentionally. I apologize for the
inconvenience, promise that we'll do our best to keep the irritations to a
minimum, and ask for your help in flagging issues that come up so that we
can get the system into a good state.

Thank you to everyone who has already provided feedback in this thread.

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

Re: Updating 32-bit Windows users to 64-bit Windows builds?

[Eric Rahm]

I filed bug 1274659 [1] to track this proposal and attempted to summarize
the issues brought up. Please add any technical comments and blocking bugs
there.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1274659

-e

On Fri, May 20, 2016 at 5:56 AM, Tobias B. Besemer <
tobias.bese...@googlemail.com> wrote:

> Am Freitag, 20. Mai 2016 01:48:24 UTC+2 schrieb Robert Strong:
> > On Thu, May 19, 2016 at 3:18 PM, Tobias B. Besemer wrote:
> >
> > > Am Freitag, 13. Mai 2016 22:41:01 UTC+2 schrieb Benjamin Smedberg:
> > > > We have considered this, but in the grand rollout plans for 64-bit
> > > Firefox
> > > > it's low on the list. We're still dealing with Flash
> > > sandboxing/functional
> > > > regressions as a blocker for wider rollout, and the next step is
> probably
> > > > to progressively roll out win64 to new users before we consider
> anything
> > > > for existing users.
> > > >
> > > > This will be much easier now that we have widevine and are dropping
> > > > npapi/silverlight, but addon compat is also a concern and we wanted
> to
> > > > partly wait for webextensions before pushing more on this.
> > > >
> > > > --BDS
> > >
> > > Sounds like a plan for me!
> > > Maybe there can be a ship of a installer that include 32bit & 64bit?
> > > Or at least have one web-installer for both versions?
> > > Also giving the user the change to make a easy upgrade from 32bit to
> 64bit
> > > with the offline-installer would be nice and a good test-drive for a
> future
> > > auto-update...
> > >
> > The installer does not equal auto-update. Two separate things entirely.
> > Download size for a combined installer is not something we want to do to
> > people on slow network connection but the auto selection via the stub
> > installer is planned though no completion date yet due to other work
> having
> > priority.
>
> The idea was to test the upgrade from 32bit to 64bit first with the
> offline installer because it should effect less people and would be maybe a
> good test for all the routines/logic behind it like e.g. uninstall
> something, moving files, or something like this...
>
> If not to much work, I would prefer to have one 32bit/64bit-installer for
> people who don't know the difference... (as default download.)
> Single Just-32bit/64bit-installer can persist for people who know for what
> they have to looking for... (AFAICR other project did/do the same.) (At
> least with just-English and multi-lang installers...)
>
> As I didn't knew how Mozilla will handle the switch... if - like by IE -
> there will be 32bit/64bit parallel, or like Chrome do it, just one
> version... I installed from each channel both version on my system and
> created a bunch of icons for it, because the version overwrite ATM the
> icons from each other...
> I guess that a lot of people have the almost same scenario (both
> versions), but by mistake and don't realize it!
> So a routine (first in offline installer) in the 64bit version that check
> if a (old) 32bit version exist too on the system and when, then de-install
> it while install/update the 64bit version would be (IMHO) nice.
> (Can test this and make QA.)
>
> Also I would like to see a error msg in future (or at least a big warning)
> if a user try to use the 32bit installer on a 64bit system.
>
> AFAIK there is also no MozillaMaintenanceService as 64bit now...
>
> ...and the MozillaMaintenanceService should also block to install a 32bit
> version on a 64bit Win (even normally no-one use this installer manual) and
> uninstall 32bit if 64bit gets installed or updated.
>
> A long open wish from me (and I guess others, too) would be to see in
> future a multi-lang web-installer. Should also make things easier...
> ___
> 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: Redesigning the docshell/loadgroup/document interaction

[Jonas Sicking]

On Fri, May 20, 2016 at 8:04 AM, Ben Kelly  wrote:
> On Fri, May 20, 2016 at 10:56 AM, Boris Zbarsky  wrote:
>
>> Thoughts?  Any obvious problems with this plan?
>
> We have the concept of network requests made from workers not associated
> with a single document.  For example, SharedWorker attached to multiple
> documents or a ServiceWorker servicing a push event.  In theory we want the
> same load grouping behavior to abort requests if those workers terminate,
> etc.
>
> If we are refactoring things, can we include that concept as well?

I *think* the current setup that we have dedicated workers is that
each worker gets its own loadgroup, and that all
XHR/fetch()/importScripts() loads are added to that loadgroup. Ideally
that loadgroup should be added as a child loadgroup of the owning
document, or the owning worker. But I'm not sure that is the case.

For SharedWorkers/ServiceWorkers, we should just skip the last step.
I.e. we should not make the loadgroup be a child of any other
loadgroup.

Is that not what we're currently doing?

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

Re: Redesigning the docshell/loadgroup/document interaction

[Ben Kelly]

On Fri, May 20, 2016 at 3:12 PM, Jonas Sicking  wrote:

> On Fri, May 20, 2016 at 8:04 AM, Ben Kelly  wrote:
> > On Fri, May 20, 2016 at 10:56 AM, Boris Zbarsky 
> wrote:
> >
> >> Thoughts?  Any obvious problems with this plan?
> >
> > We have the concept of network requests made from workers not associated
> > with a single document.  For example, SharedWorker attached to multiple
> > documents or a ServiceWorker servicing a push event.  In theory we want
> the
> > same load grouping behavior to abort requests if those workers terminate,
> > etc.
> >
> > If we are refactoring things, can we include that concept as well?
>
> I *think* the current setup that we have dedicated workers is that
> each worker gets its own loadgroup, and that all
> XHR/fetch()/importScripts() loads are added to that loadgroup. Ideally
> that loadgroup should be added as a child loadgroup of the owning
> document, or the owning worker. But I'm not sure that is the case.
>
> For SharedWorkers/ServiceWorkers, we should just skip the last step.
> I.e. we should not make the loadgroup be a child of any other
> loadgroup.
>

We don't use "child" load groups at all AFAIK.  We inherit the document
LoadGroup for dedicated workers:

https://dxr.mozilla.org/mozilla-central/source/dom/workers/WorkerPrivate.cpp#4356

I thought we also inherited the load group from a parent worker, but I
don't see the code that does it.

For SharedWorkers or workers that don't get a LoadGroup (service workers)
we override with a new load group:

https://dxr.mozilla.org/mozilla-central/source/dom/workers/WorkerPrivate.cpp#4461

We then add the tab child when a document attaches to the SharedWorker:

https://dxr.mozilla.org/mozilla-central/source/dom/workers/WorkerPrivate.cpp#3603

We then do special logic to get the first live tab child we see for the
SharedWorker out:

https://dxr.mozilla.org/mozilla-central/source/dom/workers/WorkerPrivate.cpp#2071

This tab child stuff was to support security checking on b2g I think.  I'm
not sure we strictly need it any more.

Maybe all of this is fine.  The behavior of SharedWorker and ServiceWorker
seem a bit fragile, though.  And it seems we get broken network stuff on
workers periodically for things that assume a document.  So I just wanted
to avoid any more document specific behavior if we can.  Maybe thats not a
concern here.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: FF49a1: Page load of jumping points doesn't work like it should in Wikipedia

[Adam Roach]

There is one FAQ on that page, and I think it basically says the opposite.

/a

On 5/20/16 12:35, Kartikaya Gupta wrote:

Note that this might get fixed in chrome with their new "scroll
anchoring" feature -
https://developers.google.com/web/updates/2016/04/scroll-anchoring?hl=en

kats

On Fri, May 20, 2016 at 12:15 PM, Adam Roach  wrote:

On 5/20/16 10:13, Gijs Kruitbosch wrote:

On 20/05/2016 16:11, Tobias B. Besemer wrote:

Plz open e.g. this URL:

https://en.wikipedia.org/wiki/Microsoft_Windows#Alternative_implementations

FF49a1 loads the page, jumps to "Alternative implementations", stays
there for 1-2 sec and then go ~1 screen-high (page) down.

Can someone very this bug?


The same thing happens in Chrome, so it seems like it's more likely to be
an issue with Wikipedia.


The fact that turning JavaScript off prevents this behavior would certainly
seem to support that supposition.

--
Adam Roach
Principal Platform Engineer
Office of the CTO

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



--
Adam Roach
Principal Platform Engineer
Office of the CTO
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: FF49a1: Page load of jumping points doesn't work like it should in Wikipedia

[Adam Roach]

Ah, I think I spoke to quickly -- the jumping is caused by javascript, 
but not by javascript scrolling. It's certainly possible that javascript 
hiding of large elements would be treated as reflow events by this 
approach...


/a

On 5/20/16 15:19, Adam Roach wrote:

There is one FAQ on that page, and I think it basically says the opposite.

/a

On 5/20/16 12:35, Kartikaya Gupta wrote:

Note that this might get fixed in chrome with their new "scroll
anchoring" feature -
https://developers.google.com/web/updates/2016/04/scroll-anchoring?hl=en

kats

On Fri, May 20, 2016 at 12:15 PM, Adam Roach  wrote:

On 5/20/16 10:13, Gijs Kruitbosch wrote:

On 20/05/2016 16:11, Tobias B. Besemer wrote:

Plz open e.g. this URL:

https://en.wikipedia.org/wiki/Microsoft_Windows#Alternative_implementations

FF49a1 loads the page, jumps to "Alternative implementations", stays
there for 1-2 sec and then go ~1 screen-high (page) down.

Can someone very this bug?

The same thing happens in Chrome, so it seems like it's more likely to be
an issue with Wikipedia.

The fact that turning JavaScript off prevents this behavior would certainly
seem to support that supposition.

--
Adam Roach
Principal Platform Engineer
Office of the CTO

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



--
Adam Roach
Principal Platform Engineer
Office of the CTO



--
Adam Roach
Principal Platform Engineer
Office of the CTO
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Starting to contribute (Need Help!!)

[mistry . 1]

Hi everyone! 
I am an undergraduate student and I want to start contributing to the Mozilla 
community. So it would be awesome if someone could tell me where to start from 
specifically and also what should I learn before starting. 

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

Re: Starting to contribute (Need Help!!)

[Mike Hoye]

On 2016-05-20 4:23 PM, mistr...@iitj.ac.in wrote:

Hi everyone!
I am an undergraduate student and I want to start contributing to the Mozilla 
community. So it would be awesome if someone could tell me where to start from 
specifically and also what should I learn before starting.

Hi!

Thanks for your interest; there are a few ways you can get started.

The Contribute page here: https://www.mozilla.org/en-US/contribute/

can give you some good suggestions, and in a more question-and-answer 
format you can look at


http://whatcanidoformozilla.org/

If those don't point you in the right direction, feel free to email me 
directly and we can try to figure out what you're interested in and how 
we can find a place to put your effort that would be a good fit.


Thank you,

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

Re: Redesigning the docshell/loadgroup/document interaction

[Jonas Sicking]

On Fri, May 20, 2016 at 12:28 PM, Ben Kelly  wrote:
> On Fri, May 20, 2016 at 3:12 PM, Jonas Sicking  wrote:
>>
>> On Fri, May 20, 2016 at 8:04 AM, Ben Kelly  wrote:
>> > On Fri, May 20, 2016 at 10:56 AM, Boris Zbarsky 
>> > wrote:
>> >
>> >> Thoughts?  Any obvious problems with this plan?
>> >
>> > We have the concept of network requests made from workers not associated
>> > with a single document.  For example, SharedWorker attached to multiple
>> > documents or a ServiceWorker servicing a push event.  In theory we want
>> > the
>> > same load grouping behavior to abort requests if those workers
>> > terminate,
>> > etc.
>> >
>> > If we are refactoring things, can we include that concept as well?
>>
>> I *think* the current setup that we have dedicated workers is that
>> each worker gets its own loadgroup, and that all
>> XHR/fetch()/importScripts() loads are added to that loadgroup. Ideally
>> that loadgroup should be added as a child loadgroup of the owning
>> document, or the owning worker. But I'm not sure that is the case.
>>
>> For SharedWorkers/ServiceWorkers, we should just skip the last step.
>> I.e. we should not make the loadgroup be a child of any other
>> loadgroup.
>
>
> We don't use "child" load groups at all AFAIK.  We inherit the document
> LoadGroup for dedicated workers:
>
> https://dxr.mozilla.org/mozilla-central/source/dom/workers/WorkerPrivate.cpp#4356

That doesn't sound good. We should give each worker its own loadgroup.
Independent of if it's a dedicated, shared or service worker.

Or is there a reason to share loadgroup with the document that I'm missing?

> I thought we also inherited the load group from a parent worker, but I don't
> see the code that does it.
>
> For SharedWorkers or workers that don't get a LoadGroup (service workers) we
> override with a new load group:
>
> https://dxr.mozilla.org/mozilla-central/source/dom/workers/WorkerPrivate.cpp#4461
>
> We then add the tab child when a document attaches to the SharedWorker:
>
> https://dxr.mozilla.org/mozilla-central/source/dom/workers/WorkerPrivate.cpp#3603

This looks like the worker loadinfo, which is different from the
loadgroup (and also different from nsILoadInfo, despite the same name
sadly).

> https://dxr.mozilla.org/mozilla-central/source/dom/workers/WorkerPrivate.cpp#2071
>
> This tab child stuff was to support security checking on b2g I think.  I'm
> not sure we strictly need it any more.
>
> Maybe all of this is fine.  The behavior of SharedWorker and ServiceWorker
> seem a bit fragile, though.  And it seems we get broken network stuff on
> workers periodically for things that assume a document.  So I just wanted to
> avoid any more document specific behavior if we can.  Maybe thats not a
> concern here.

It's generally a concern that we still have a lot of code which rely
on loads happening through a document.

In part because it's convenient to have a single object through which
you can get all needed information when doing "networky stuff".

The best solution i've been able to think of so far is to rely less on
nsILoadContext (which is strongly tied to docshells, which workers
don't always have) and more on nsILoadInfo (which is information
sitting directly on channels). We're at the point now where we should
be able to start deprecating stuff off of nsILoadContext.

Something like this would also be very helpful:
https://bugzilla.mozilla.org/show_bug.cgi?id=1259873

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

Re: Redesigning the docshell/loadgroup/document interaction

[Jonas Sicking]

On Fri, May 20, 2016 at 4:04 PM, Ben Kelly  wrote:
> On May 20, 2016 6:14 PM, "Jonas Sicking"  wrote:
>> That doesn't sound good. We should give each worker its own loadgroup.
>> Independent of if it's a dedicated, shared or service worker.
>>
>> Or is there a reason to share loadgroup with the document that I'm
>> missing?
>
> Not sure.  I think it's been that way for a long time.  I just added the
> code to create a load group if we didn't get one from the document.

Yeah, I think this was done the wrong way from the beginning. It
didn't matter that much when we just had dedicated workers. But now
that we have ServiceWorkers/SharedWorkers, I think it's making our
world more complicated.

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

Re: IPCStream landed in mozilla-central

[Ben Kelly]

On Fri, May 20, 2016 at 11:09 AM, Ben Kelly  wrote:

> On Fri, May 20, 2016 at 7:37 AM, Honza Bambas  wrote:
>
>> And I do! :)  Actually any parent necko channel, mainly HTTP, which sends
>> data to the child process.  We also have bug 1110596 which complains about
>> too much memory copying in that code.
>> Could your IPCStream be used for that?
>>
>
> Yes, I think that could work in general.
>
> I think the main issue would be compat with existing nsIStreamListeners.
> These listeners might be written such that they expect the nsIInputStream
> passed in OnDataAvailable() to return their entire length from a single
> Available() call.  This will not be true for a streamed pipe.
>

Actually, the nsIStreamListener interface explicitly requires a fixed
length nsIInputStream:

"The onDataAvailable impl must read exactly |aCount| bytes of data before
returning."

From:

https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIStreamListener.idl#18

I don't think we can use a pipe-oriented stream here without changing that
interface contract.

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

Re: Redesigning the docshell/loadgroup/document interaction

[Ben Kelly]

On May 20, 2016 6:14 PM, "Jonas Sicking"  wrote:
> That doesn't sound good. We should give each worker its own loadgroup.
> Independent of if it's a dedicated, shared or service worker.
>
> Or is there a reason to share loadgroup with the document that I'm
missing?

Not sure.  I think it's been that way for a long time.  I just added the
code to create a load group if we didn't get one from the document.

I thought the load group was related to the tab child because the group has
notification callbacks, etc.

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

Re: IPCStream landed in mozilla-central

[Ben Kelly]

On Fri, May 20, 2016 at 8:10 PM, Ben Kelly  wrote:

> On Fri, May 20, 2016 at 11:09 AM, Ben Kelly  wrote:
>
>> On Fri, May 20, 2016 at 7:37 AM, Honza Bambas 
>> wrote:
>>
>>> And I do! :)  Actually any parent necko channel, mainly HTTP, which
>>> sends data to the child process.  We also have bug 1110596 which complains
>>> about too much memory copying in that code.
>>> Could your IPCStream be used for that?
>>>
>>
>> Yes, I think that could work in general.
>>
>> I think the main issue would be compat with existing nsIStreamListeners.
>> These listeners might be written such that they expect the nsIInputStream
>> passed in OnDataAvailable() to return their entire length from a single
>> Available() call.  This will not be true for a streamed pipe.
>>
>
> Actually, the nsIStreamListener interface explicitly requires a fixed
> length nsIInputStream:
>
> "The onDataAvailable impl must read exactly |aCount| bytes of data before
> returning."
>
> From:
>
>
> https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIStreamListener.idl#18
>
> I don't think we can use a pipe-oriented stream here without changing that
> interface contract.
>

Is there a reason we can't just make necko code call OnDataAvailable()
multiple times with a different slice of the giant buffer?  It already has
the mechanism for chunked data.  It just needs to split the single buffer
into multiple callouts.

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