Re: Intent to implement: File system provider API

[Sean Lee]

On Mon, Jul 27, 2015 at 7:31 PM, Ted Mielczarek  wrote:

> On Fri, Jul 24, 2015, at 12:43 PM, Jonas Sicking wrote:
> > On Fri, Jul 24, 2015 at 3:49 AM, David Rajchenbach-Teller
> >  wrote:
> > > On 24/07/15 11:38, Jonas Sicking wrote:
> > >> I think we should allow addons to implement something like this. But I
> > >> don't think it's something that we should let apps do.
> > >>
> > >> / Jonas
> > >
> > > So Dropbox, Cozy Cloud, etc. should be add-ons instead of apps?
> >
> > Yes. For FirefoxOS we're working on getting rid of installation for
> > "apps". Instead apps will be treated just like other web content that
> > you simply browse to.
> >
> > In this model it doesn't make as much sense for apps to be changing
> > the behavior of the user agent. Why would navigating to Dropbox and
> > then navigating away from it suddenly change the behavior of your OS?
> > How do you revert it?
> >
> > Instead we're going to use addons as the way that you customize your
> > device.
>
> I've been actually thinking about this exact use case recently (storage
> providers) and I think it would behoove us to figure out how to make
> this work for webapps. If you require addons to make this work then
> every storage provider needs to write addons for every browser, which
> means that they're likely to just not have support for Firefox OS. If
> you make this a web app feature instead, then providers can simply use
> the web API and any user agent that supports it will get support,
> meaning that Firefox OS is likely to be supported.
>
This is pretty similar in spirit to the existing
> navigator.registerProtocolHandler, although I don't know how well that
> API has fared in practice.
>
> I think letting web apps extend the browser's capabilities is a good and
> useful thing, and we should do more of it.
>

I agree that web apps extend the browser's current capabilities is a good
way,
but there is a limitation that a video file has to be downloaded entirely
and assign
the video to a video tag than. (File-based Implementation)
Users have to wait for file downloaded entirely than watch the video,so the
response time is too long to enjoy media files.

Media Source Extension is a tool for playing the partial content which is
steamed,
but the challenge with HTML5 audio and video is still the fragmented
support for
audio and video formats. However, fragmented video/audio is not a very
common
format for users.

If one file reading request can split into multiple blocks/requests and the
content
still can be played normally, the response time can be shorten.
(Block-based)

The file reading request from Device Storage API will split into multiple
requests
by FUSE like this:
static int bindings_read (const char *path, char *buf, size_t len, off_t
offset, struct fuse_file_info *info)

so file system provider can handle the above request to retrieve the
partial content at offset.
For example, the content consumer of Video player can play the partial
content once it is retrieved.

Thanks.


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



-- 
Sean Lee
Front-End Software Engineer, Firefox OS Devices
Mozilla Corporation
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: large memory allocations / resource consumption in crashtests?

[Karl Tomlinson]

Thanks everyone.  That gives me some ideas on how to clean up
after the page.  I figure that then any OOM issues will at least
be in the vicinity of the test doing the large allocation.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA/FYI: Changes to the Core::Video/Audio Bugzilla component

[Ehsan Akhgari]

On Mon, Jul 27, 2015 at 2:42 PM, Maire Reavy  wrote:

>1. Video/Audio: Playback
>2. Video/Audio: MSG/cubeb
>3. Video/Audio: Recording
>4. WebRTC
>5. Web Audio


The first three seem to start with "Audio/Video:".
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: Request.context

[falken]

On Tuesday, July 28, 2015 at 6:56:40 AM UTC+9, Ehsan Akhgari wrote:
> The web compat effect should be minimal if existent, as we have never
> exposed any useful values from this attribute, and no other UAs ship it.

Just for reference, Chrome 44 shipped this too:
https://www.chromestatus.com/features/4699713102151680

It's probably still early enough to unship or change. I've updated the 
dashboard to point to this thread.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: Request.context

[Ben Kelly]

On Mon, Jul 27, 2015 at 5:55 PM, Ehsan Akhgari 
wrote:

> This was shipped in Firefox 39, but this attribute is fairly useless
> without service workers since it can only be read from Request objects and
> its value will always be "fetch" for manually created Request objects.


Actually, it sounds like we're not quite right there either.  It should now
be "" for synthetically created Request objects.  The fetch() method copies
to a new Request object with "fetch" context.  Thats not observable without
the fetch event, though.

Anyway, that's beside the point right now if we are disabling it.

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

Re: Intent to implement: File system provider API

[Jonas Sicking]

On Mon, Jul 27, 2015 at 4:31 AM, Ted Mielczarek  wrote:
> On Fri, Jul 24, 2015, at 12:43 PM, Jonas Sicking wrote:
>> On Fri, Jul 24, 2015 at 3:49 AM, David Rajchenbach-Teller
>>  wrote:
>> > On 24/07/15 11:38, Jonas Sicking wrote:
>> >> I think we should allow addons to implement something like this. But I
>> >> don't think it's something that we should let apps do.
>> >>
>> >> / Jonas
>> >
>> > So Dropbox, Cozy Cloud, etc. should be add-ons instead of apps?
>>
>> Yes. For FirefoxOS we're working on getting rid of installation for
>> "apps". Instead apps will be treated just like other web content that
>> you simply browse to.
>>
>> In this model it doesn't make as much sense for apps to be changing
>> the behavior of the user agent. Why would navigating to Dropbox and
>> then navigating away from it suddenly change the behavior of your OS?
>> How do you revert it?
>>
>> Instead we're going to use addons as the way that you customize your
>> device.
>
> I've been actually thinking about this exact use case recently (storage
> providers) and I think it would behoove us to figure out how to make
> this work for webapps.

I agree that it's great if we can expose this to web content.

I don't think registerProtocolHandler has nearly enough API surface to
support what's needed here. But if you mean copying the idea that
there's a function call which displays a UI prompt which allows the
user to accept/deny then that could work.

One important question here is once, say, Box has registered as
filesystem provider, does that mean that other websites can read/write
there without any prompts?

If not, who provides the UI of those prompts? Does the browser provide
that UI, or do we somehow enable Box to display that UI?

This also affects what the UI looks like at time of registration.

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

Re: Intent to implement: File system provider API

[Jonas Sicking]

On Sun, Jul 26, 2015 at 8:42 PM, Shih-Chiang Chien  wrote:
> Hi Jonas,
>
> Is there any document or bug for the new addon architecture? We'd like to
> know more details and put it into our design.

I'd recommend reaching out to William McCloskey. He's currently
working on the desktop support. I suspect there will be more things to
point to once the initial support has landed.

/ Jonas




> Best Regards,
> Shih-Chiang Chien
> Mozilla Taiwan
>
> On Mon, Jul 27, 2015 at 6:31 AM, Jonas Sicking  wrote:
>>
>> On Sat, Jul 25, 2015 at 7:14 AM, Kershaw Chang 
>> wrote:
>> > Since the addon model on Firefox OS is not implemented now, I still use
>> > the
>> > old term "apps" in previous mail.
>> > I also think it makes much more sense to make this API to be only
>> > available
>> > for addons.
>>
>> Great!
>>
>> > In addition, do we have a way to let an API only be used by addons now?
>>
>> We don't currently. But that should be available soon once the new
>> addon architecture lands.
>>
>> / Jonas
>> ___
>> 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

Intent to unship: Request.context

[Ehsan Akhgari]

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

APIs to be removed: Request.context

This was shipped in Firefox 39, but this attribute is fairly useless
without service workers since it can only be read from Request objects and
its value will always be "fetch" for manually created Request objects.

It has become clear that the meaning of this attribute needs to change in
the fetch spec, so I think it is best for us to unship this attribute for
now, and expose it again once the spec has settled.

The web compat effect should be minimal if existent, as we have never
exposed any useful values from this attribute, and no other UAs ship it.

I'm planning to unship this in Firefox 42.

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

PSA/FYI: Changes to the Core::Video/Audio Bugzilla component

[Maire Reavy]

Hi all,

There are a few Bugzilla updates to the Core::Video/Audio bugs that I and
the other media folks wanted everyone working on the project to know about.

The Core::Video/Audio component has been renamed and reorganized a bit.
Core::Video/Audio is now called Core::Audio/Video, and it has become a top
level module for media bugs that need to be triaged.

The triage for Audio/Video is not complete (because we just decided to make
this change), but it will be happening over the next few weeks.  Sorry in
advance for any "bug spam" as bugs get moved. Going forward, when a
Core::Audio/Video (media) bug is triaged, it will move to one of these
categories:

   1. Video/Audio: Playback
   2. Video/Audio: MSG/cubeb
   3. Video/Audio: Recording
   4. WebRTC
   5. Web Audio

I asked to make this change because the old Core::Video/Audio component was
too large, too tough to "watch", and bugs that my team needed to work on
(i.e. non-Playback bugs) were getting lost there.

For reference:

   - Playback covers bugs involving the  &  tags, MSE, EME,
   MP4, WebM -- as well as any decoding bugs.
   - MSG/cubeb covers the "internals" of how media is played -- including
   MediaStreamGraph (MSG), drivers (cubeb), and GMP (Gecko Media Plugin) -- as
   well as any encoding bugs.
   - Recording covers any bugs related to the recording/encoding of audio
   and video using the HTML5 MediaRecorder API.
   - WebRTC and Web Audio are pretty self explanatory.

Please start filing bugs in the appropriate sub-component if you know where
to file them.  If you don't know where they belong, you can still file them
in Core::Audio/Video.

Similarly. if you want to move a bug you filed or are viewing from
Core::Audio/Video to the new component, please do so.  You will help us by
doing this.  (We have a bunch of backlog to burn through.)

Also remember that if you were watching the Video/Audio Bugzilla component,
you'll need to update your Bugzilla Preferences to watch the new
sub-component you care about (e.g. Playback, MSG/Cubeb).

Finally, if you have any questions about Playback bugs, reach out to
Anthony Jones and/or Chris Pearce.  For questions about any other media
bugs, you can reach out to me, Randell Jesup and/or Paul Adenot.  We all
hang out in #media on irc.

Thanks & Cheers,
-Maire

-- 
Maire Reavy
mre...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: what is new in talos, what is coming up

[jmaher]

It has been a while since we posted an update on Talos

Here are some new things:
* bug 1166132 - new tps test - tab switching
* e10s on all platforms, only runs on mozilla-central for pgo builds, broken 
tests, big regressions are tracked in bug 1144120
* perfherder is easier to use, some polish on test selection and the compare 
view, and most importantly we have found a few odd bugs that has caused 
duplicate data to show up, check it out: 
https://treeherder.mozilla.org/perf.html#/graphs

Here is what is upcoming:
* moving talos source code in-tree (bug 787200)
* starting to move android talos to autophone (bug 1170685)
* perfherder: easier to find it when pushing to try and more polish on 
selecting which revisions to compare against.
* automatic 5 retriggers for talos jobs on try server

As always if you have issues you can file bugs:
* talos: 
https://bugzilla.mozilla.org/enter_bug.cgi?product=Testing&component=Talos
* perfherder: 
https://bugzilla.mozilla.org/enter_bug.cgi?product=Tree%20Management&component=Perfherder

Thanks for responding to regressions when pinged!  Expect another update 
sometime in late August or early September.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: File system provider API

[Eden Chuang]

For FirefoxOS devices, I think FileSystemProviderAPI provides a capability
to connect to other type of storage, not only well-known cloud storage, for
example Dropbox, but also user's private cloud. With FileSystemProviderAPI,
FirefoxOS provides apps a general or easy way, for example
DeviceStorageAPI, to access all kinds of storage.

I guess that storage providers might not be the one who write the storage
app or addon, OEM might also be the possible one, for example Panasonic
writes a Dropbox Addon for their smart TV to let user can play the pictures
or videos on the TV directly.


2015-07-27 22:48 GMT+08:00 Kershaw Chang :

> The motivation behind this is to let Firefox OS has the ability to access
> files on cloud storage. With file system provider API, we can allow device
> storage API to read/write files on cloud storage seamlessly. From user's
> point of view, I think it would be better to use our current
> music/video/gallery apps to acces user's files on cloud, but not other
> apps.
>
>
> On Mon, Jul 27, 2015 at 8:00 PM, Ted Mielczarek 
> wrote:
>
> > On Fri, Jul 24, 2015, at 04:13 AM, Kershaw Chang wrote:
> > > Link to standard:
> > > No formal specifications found on w3c. This API is only supported by
> > > Chrome
> > > OS now.
> >
> > What's the motivation here? Do we expect this to get used by apps if
> > it's Chrome OS only right now? I've been looking into this problem space
> > (cloud storage for use by webapps) and the neatest thing I've run into
> > so far is https://remotestorage.io/ . That has the benefit of being
> > entirely content-side right now, which seems like a smart way to start
> > out. Extending something like that with browser hooks to make it better
> > seems like a smarter play than copying Chrome privileged APIs.
> >
> > -Ted
> > ___
> > 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: Intent to implement: File system provider API

[Kershaw Chang]

The motivation behind this is to let Firefox OS has the ability to access
files on cloud storage. With file system provider API, we can allow device
storage API to read/write files on cloud storage seamlessly. From user's
point of view, I think it would be better to use our current
music/video/gallery apps to acces user's files on cloud, but not other apps.


On Mon, Jul 27, 2015 at 8:00 PM, Ted Mielczarek  wrote:

> On Fri, Jul 24, 2015, at 04:13 AM, Kershaw Chang wrote:
> > Link to standard:
> > No formal specifications found on w3c. This API is only supported by
> > Chrome
> > OS now.
>
> What's the motivation here? Do we expect this to get used by apps if
> it's Chrome OS only right now? I've been looking into this problem space
> (cloud storage for use by webapps) and the neatest thing I've run into
> so far is https://remotestorage.io/ . That has the benefit of being
> entirely content-side right now, which seems like a smart way to start
> out. Extending something like that with browser hooks to make it better
> seems like a smarter play than copying Chrome privileged APIs.
>
> -Ted
> ___
> 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: large memory allocations / resource consumption in crashtests?

[smaug]

On 07/27/2015 04:07 PM, Ehsan Akhgari wrote:

On 2015-07-27 5:35 AM, Karl Tomlinson wrote:

Is anything done between crashtests to clean up memory use?


There isn't, AFAIK.


Or can CC be triggered to run during or after a particular crashtest?


You can use SimpleTest.forceGC/CC() as needed.


Do crashtests go into B/F cache on completion, or can we know that
nsGlobalWindow::CleanUp() or FreeInnerObjects() will run on completion?


I'm pretty sure that pages are put into the bf cache if possible as usual.




And you can test that by using pagehide event listener and check .persisted 
property.
If you explicitly want to prevent bfcache for certain page, just add a dummy 
unload event listener.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: large memory allocations / resource consumption in crashtests?

[Ehsan Akhgari]

On 2015-07-27 5:35 AM, Karl Tomlinson wrote:

Is anything done between crashtests to clean up memory use?


There isn't, AFAIK.


Or can CC be triggered to run during or after a particular crashtest?


You can use SimpleTest.forceGC/CC() as needed.


Do crashtests go into B/F cache on completion, or can we know that
nsGlobalWindow::CleanUp() or FreeInnerObjects() will run on completion?


I'm pretty sure that pages are put into the bf cache if possible as usual.

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

Re: Mozilla will stop producing automated builds of XULRunner after the 41.0 cycle

[Ben Hearsum]

Looks good to me, thank you for doing that!

On 2015-07-27 03:15 AM, Teoli wrote:
> Ben, I have updated:
> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/XULRunner
> 
> Can you double check it?
> 
> On 13/07/2015 16:48, Ben Hearsum wrote:
>> Hi folks,
>>
>> XULRunner is a runtime package that can be used to run XUL+XPCOM based
>> applications. Automated builds of it have been produced alongside
>> Firefox since 2006, but it has not been a supported or resourced product
>> for many years. We've continued to produce automated builds of it
>> because its build process also happens to build the Gecko SDK, which we
>> do support and maintain. This will change soon, and we'll start building
>> the Gecko SDK from Firefox instead (bug 672509). This work will land on
>> mozilla-central during the 42.0 cycle, which means that when the 41.0
>> cycle ends (September 22, 2015), automated builds of XULRunner will
>> cease.
>>
>> If you are a consumer of the Gecko SDK this means very little to you --
>> we will continue to produce it with every Firefox release.
>>
>> If you are a consumer of the XULRunner stub this means that you will no
>> longer have a Mozilla produced version after 41.0. For folks in this
>> group, you have two options:
>> * Change your app to run through the stub provided by Firefox. Many apps
>> will continue to work as before by simply replacing "xulrunner.exe
>> application" with "firefox -app application.ini".
>> * Build XULRunner yourself.
>>
>> - Ben
>>
> 

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

Re: large memory allocations / resource consumption in crashtests?

[Kyle Huey]

On Mon, Jul 27, 2015 at 2:35 AM, Karl Tomlinson  wrote:
> Sometimes it would be nice to check in crashtests that use, or
> attempt to use large memory allocations, but I'm concerned that
> checking in these crashtests could disrupt subsequent tests
> because there is then not enough memory to test what they want to
> test.

It seems like it should be a goal that we continue to operate
successfully after navigating away from a page that uses a large
amount of memory.  In practice ...

> Is anything done between crashtests to clean up memory use?
> Or can CC be triggered to run during or after a particular crashtest?

Nothing other than the normal heuristics.  If you look at logs from a
debug build you'll see points where we do a GC/CC and clean up windows
from the last several tests.

> Do crashtests go into B/F cache on completion, or can we know that
> nsGlobalWindow::CleanUp() or FreeInnerObjects() will run on completion?

That I don't know, but it should be easy to test locally.

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

Re: Intent to implement: File system provider API

[Ted Mielczarek]

On Fri, Jul 24, 2015, at 04:13 AM, Kershaw Chang wrote:
> Link to standard:
> No formal specifications found on w3c. This API is only supported by
> Chrome
> OS now.

What's the motivation here? Do we expect this to get used by apps if
it's Chrome OS only right now? I've been looking into this problem space
(cloud storage for use by webapps) and the neatest thing I've run into
so far is https://remotestorage.io/ . That has the benefit of being
entirely content-side right now, which seems like a smart way to start
out. Extending something like that with browser hooks to make it better
seems like a smarter play than copying Chrome privileged APIs.

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

Re: Intent to implement: File system provider API

[Ted Mielczarek]

On Fri, Jul 24, 2015, at 12:43 PM, Jonas Sicking wrote:
> On Fri, Jul 24, 2015 at 3:49 AM, David Rajchenbach-Teller
>  wrote:
> > On 24/07/15 11:38, Jonas Sicking wrote:
> >> I think we should allow addons to implement something like this. But I
> >> don't think it's something that we should let apps do.
> >>
> >> / Jonas
> >
> > So Dropbox, Cozy Cloud, etc. should be add-ons instead of apps?
> 
> Yes. For FirefoxOS we're working on getting rid of installation for
> "apps". Instead apps will be treated just like other web content that
> you simply browse to.
> 
> In this model it doesn't make as much sense for apps to be changing
> the behavior of the user agent. Why would navigating to Dropbox and
> then navigating away from it suddenly change the behavior of your OS?
> How do you revert it?
> 
> Instead we're going to use addons as the way that you customize your
> device.

I've been actually thinking about this exact use case recently (storage
providers) and I think it would behoove us to figure out how to make
this work for webapps. If you require addons to make this work then
every storage provider needs to write addons for every browser, which
means that they're likely to just not have support for Firefox OS. If
you make this a web app feature instead, then providers can simply use
the web API and any user agent that supports it will get support,
meaning that Firefox OS is likely to be supported.

This is pretty similar in spirit to the existing
navigator.registerProtocolHandler, although I don't know how well that
API has fared in practice.

I think letting web apps extend the browser's capabilities is a good and
useful thing, and we should do more of it.

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

[Firefox Desktop] Issues found: July 20th to July 24th

[Andrei Vaida]

Hi everyone,

A list of the new issues found and filed by the Desktop Manual QA team 
last week (Week 30: July 20 - July 24) is available below.


Additional details on the team's priorities last week, as well as the 
plans for the current week can be found at: 
https://etherpad.mozilla.org/DesktopManualQAWeeklyStatus.


*Release Channel:*
No bugs.

*Beta Channel:*
NEW Bug 1185977  - 
A Scroll Bar is displayed in Loop Panel for a long Conversation Name

 • /Regression:/ No.
 • /Severity:/ Normal.
 • /Assigned To:/ NOBODY.
NEW Bug 1187306  - 
[Windows 10] Taskbar context menu items not working when installed 
without Start Menu shortcut

 • /Regression:/ No.
 • /Severity:/ Normal.
 • /Assigned To:/ NOBODY.
NEW Bug 1187308  - 
crash in OOM | large | mozalloc_abort(char const* const) | 
mozalloc_handle_oom(unsigned int) | moz_xmalloc | 
webrtc::ViEExternalRendererImpl::RenderFrame(unsigned int, 
webrtc::I420VideoFrame&)

 • /Regression:/ No.
 • /Severity:/ Critical.
 • /Assigned To:/ NOBODY.

*Aurora Channel:*
No bugs.

*Nightly Channel:*
RESO Bug 1185889  
- [Windows 10] Close tab icon is incorrectly displayed for DevEdition 
Theme on nightly

 • /Regression//:/ Yes, since 2015-07-18.
 • /Severity:/ Normal.
 • /Assigned To:/ Tim Nguyen [:ntim] .
NEW Bug 1185968  - 
[HiDPI] Hello conversation window is cut-off when several calls are listed

 • /Regression:/ No.
 • /Severity:/ Normal.
 • /Assigned To:/ NOBODY.
NEW Bug 1186351  - 
[HiDPI][Tablet Mode] Back button is smaller than the URL/search bar in 
Dev Edition on Windows 10

 • /Regression:/ Yes, caused by Bug 1184728 .
 • /Severity:/ Normal.
 • /Assigned To:/ NOBODY.
NEW Bug 1186393  - 
Some search add-ons don't perform searches from awesome bar

 • /Regression:/ Yes, caused by Bug 1168811 .
 • /Severity:/ Normal.
 • /Assigned To:/ NOBODY.
NEW Bug 1186842  - 
Unresponsive keyboard buttons using a PDF file

 • /Regression:/ No.
 • /Severity:/ Normal.
 • /Assigned To:/ NOBODY.
NEW Bug 1186890  - 
[e10s] Navigation doesn't exit fullscreen correctly

 • /Regression:/ Yes, since 2015-05-27.
 • /Severity:/ Normal.
 • /Assigned To:/ NOBODY.
NEW Bug 1187287  - 
[Ubuntu] Unreadable e10s infobar

 • /Regression:/ Yes, since 2015-07-23.
 • /Severity:/ Normal.
 • /Assigned To:/ NOBODY.
NEW Bug 1186892  - 
[Windows]Strikethrough visual bug for pages that have insecure content 
loaded

 • /Regression:/ Pending further investigation.
 • /Severity:/ Normal.
 • /Assigned To:/ NOBODY.

*ESR Channel:*
No bugs.

Regards,
Andrei Vaida | QC Engineer

SOFTVISION | Independentei 2B Street, Baia Mare, Romania
Email: andrei.va...@softvision.ro | Web: www.softvision.ro

The content of this communication is classified as SOFTVISION 
Confidential and Proprietary Information.



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

large memory allocations / resource consumption in crashtests?

[Karl Tomlinson]

Sometimes it would be nice to check in crashtests that use, or
attempt to use large memory allocations, but I'm concerned that
checking in these crashtests could disrupt subsequent tests
because there is then not enough memory to test what they want to
test.

Is anything done between crashtests to clean up memory use?
Or can CC be triggered to run during or after a particular crashtest?

Do crashtests go into B/F cache on completion, or can we know that
nsGlobalWindow::CleanUp() or FreeInnerObjects() will run on completion?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: New reftest analyzer keyboard shortcuts

[Ting-Yu Lin]

kats, keyboard shortcuts are convenient.

BTW, I filed bug 1187774 and added some thoughts for making the keyboard
shortcuts discoverable.

TYLin

On Fri, Jul 24, 2015 at 9:37 PM, Kartikaya Gupta  wrote:

> Since keyboard shortcuts aren't very discoverable this is just a note
> to let you all know that in bug 1187025 I added some more keyboard
> shortcuts to the reftest analyzer. Previously '1' and '2' would switch
> between the test/reference images, and now 'd' will toggle the
> differences view and 'p' and 'n' will go to the previous/next result.
>
> Happy keyboarding!
>
> kats
> ___
> 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: Mozilla will stop producing automated builds of XULRunner after the 41.0 cycle

[Teoli]

Ben, I have updated: 
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/XULRunner


Can you double check it?

On 13/07/2015 16:48, Ben Hearsum wrote:

Hi folks,

XULRunner is a runtime package that can be used to run XUL+XPCOM based
applications. Automated builds of it have been produced alongside
Firefox since 2006, but it has not been a supported or resourced product
for many years. We've continued to produce automated builds of it
because its build process also happens to build the Gecko SDK, which we
do support and maintain. This will change soon, and we'll start building
the Gecko SDK from Firefox instead (bug 672509). This work will land on
mozilla-central during the 42.0 cycle, which means that when the 41.0
cycle ends (September 22, 2015), automated builds of XULRunner will cease.

If you are a consumer of the Gecko SDK this means very little to you --
we will continue to produce it with every Firefox release.

If you are a consumer of the XULRunner stub this means that you will no
longer have a Mozilla produced version after 41.0. For folks in this
group, you have two options:
* Change your app to run through the stub provided by Firefox. Many apps
will continue to work as before by simply replacing "xulrunner.exe
application" with "firefox -app application.ini".
* Build XULRunner yourself.

- Ben



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