Re: Service Worker - Offline fallback not working

2016-05-30 Thread Ben Kelly 
On May 30, 2016 1:55 PM, "Mohit Bajoria"  wrote:
> Offline fallback event is not working.
> Can anyone please let me know the error and help me solving the issue ?

Can you describe what you expect and what you are actually seeing happen?

There is no "offline fallback event", so not sure exactly what you mean.

Thanks.

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

Service Worker - Offline fallback not working

2016-05-30 Thread Mohit Bajoria 
Hello developers

I am trying to use service workers and i am facing problem regarding offline 
fallback. Can anyone please help :)

Project source code - https://github.com/mbj36/My-Blog/tree/gh-pages

Offline fallback event is not working. 
Can anyone please let me know the error and help me solving the issue ?

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

Re: How to name our JSContext getter(s): let the bikeshed begin

2016-05-30 Thread Kyle Huey 
On Sun, May 29, 2016 at 6:21 PM, Boris Zbarsky  wrote:
> On 5/29/16 6:17 PM, Kyle Huey wrote:
>>
>> Do we really need the ForThread part?
>
>
> I wanted to make it clear that we're getting something that's OK to use
> without synchronization, but maybe that's redundant and we can just have a
> dom::GetJSContext() or something.  dom::JSContext() would have ambiguity
> issues, of course.  I don't have super-strong opinions here.
>
>> Is the long term plan to merge
>> JSRuntime and JSContext, or are they going to remain distinct
>> indefinitely?
>
>
> Unclear.  See discussion the SpiderMonkey folks are having starting at
> https://bugzilla.mozilla.org/show_bug.cgi?id=650361#c27

Segregating the thread-specific and thread-agnostic parts into
separate classes seems like a good idea.

Given that it only makes sense to use a thread-specific object on that
thread, and it only makes sense to get the thread-agnostic object here
*from TLS* on one thread, I don't think we need any "thread" naming.

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

Re: Intent to deprecate: MacOS 10.6-10.8 support

2016-05-30 Thread Ralph Giles 
Yes, that's fine assuming it builds on try. Official builds will be
happening on 10.7 for a while yet.

 -r

On Sun, May 29, 2016 at 3:59 PM, Chris Pearce  wrote:
> So, given that users won't be able to install Firefox on unsupported
> versions of MacOSX, and unsupported users won't be upgraded, can we proceed
> to remove all the nsCocoaFeatures::On[Mountain]LionOrLater() calls in
> Firefox 49 and just assume everywhere that MacOSX specific Gecko code is
> running on 10.9 or later?
>
>
>
> On Fri, May 27, 2016 at 4:59 PM, Ralph Giles  wrote:
>>
>> On Thu, May 26, 2016 at 3:37 PM, L. David Baron  wrote:
>>
>> > There's a screenshot in:
>> > https://bugzilla.mozilla.org/show_bug.cgi?id=1255588#c8 (and #c9)
>> > (which is the bug that made the necessary changes for the Mac OS X
>> > support change in Firefox 49).
>>
>> Ah, that's great. Thanks!
>>
>>  -r
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How to name our JSContext getter(s): let the bikeshed begin

2016-05-30 Thread smaug 

On 05/30/2016 05:46 AM, Boris Zbarsky wrote:

On 5/29/16 6:21 PM, Boris Zbarsky wrote:

I wanted to make it clear that we're getting something that's OK to use
without synchronization, but maybe that's redundant and we can just have
a dom::GetJSContext() or something.  dom::JSContext() would have
ambiguity issues, of course.  I don't have super-strong opinions here.


Another thought that just occurred to me is ThreadCx().

-Boris


I like that.
I'd prefer to have it as a static method in some class (to ease readability and 
searchability of the code), but
I admit dom::ThreadCx(); (== mozilla::dom::ThreadCx()) looks pretty nice. So I 
guess method in dom namespace is fine too.
I wonder if we should have some single place (.h/.cpp) where we put all global 
methods in dom namespace.


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

Re: Intent to implement: HTMLMediaElement::seekToNextFrame()

2016-05-30 Thread Tzu-Hao Kuo 
Yes, Xidorn, thanks. I have modified it accordingly.

*Tzuhao Kuo (Kuku)* | OS Media | *Mozilla Taipei* | M: +886-939-816-840

On Fri, May 27, 2016 at 12:45 PM, Xidorn Quan  wrote:

> On Fri, May 27, 2016 at 12:49 PM, Tzu-Hao Kuo  wrote:
>
>>
>> *Preference behind which this will be implemented*: media.seekToNextFrame
>>
>
> I guess it'd be better to call it "media.seekToNextFrame.enabled".
>
> - Xidorn
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[Firefox Desktop] Issues found: May 23rd to May 27th

2016-05-30 Thread Andrei Vaida 

Hi everyone,

Here's the list of new issues found and filed by the Desktop Release QA 
Team last week, *May 23 - May 27* (week 21).


Additional details on the team's priorities last week, as well as the 
plans for the current week are available at:


   https://public.etherpad-mozilla.org/p/DesktopManualQAWeeklyStatus



*RELEASE CHANNEL*
none

*BETA CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1275857 
	[Synced Tabs Sidebar] Not all synced tabs are displayed in Synced Tabs 
Sidebar on a second device

Firefox
Sync
NO  NOBODY


*AURORA CHANNEL*
none

*NIGHTLY CHANNEL*
none

*ESR CHANNEL*
none

Regards,
Andrei
Andrei Vaida
Team Lead
SOFTVISION

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