Closed Bug 1219468 Opened 4 years ago Closed 3 years ago

Replace PRLogModuleInfo usage with LazyLogModule in webrtc

Categories

(Core :: WebRTC, defect, P3)

defect

Tracking

()

RESOLVED FIXED
mozilla54
Tracking Status
firefox44 --- affected
firefox54 --- fixed
Blocking Flags:
backlog tech-debt

People

(Reporter: erahm, Assigned: hhraulerson, Mentored)

References

Details

(Whiteboard: [lang=c++][good first bug])

Attachments

(2 files, 4 obsolete files)

This covers replacing PRLogModuleInfo w/ LazyLogModule in the 'media/' directory.

Current usage:
> ./media/mtransport/logging.h:25:      log = PR_NewLogModule(n);                 \
> ./media/webrtc/signaling/src/common/browser_logging/CSFLog.cpp:24:    gLogModuleInfo = PR_NewLogModule("signaling");
> ./media/webrtc/signaling/src/common/browser_logging/CSFLog.cpp:34:    gWebRTCLogModuleInfo = PR_NewLogModule("webrtc_trace");
> ./media/webrtc/signaling/src/common/browser_logging/WebRtcLog.cpp:42:    sLog = PR_NewLogModule("webrtc_trace");
> ./media/webrtc/signaling/src/common/browser_logging/WebRtcLog.cpp:51:    sLog = PR_NewLogModule("AEC");
> ./media/webrtc/signaling/src/media-conduit/WebrtcGmpVideoCodec.cpp:44:    sLog = PR_NewLogModule("GMP");
> ./media/webrtc/signaling/src/peerconnection/PeerConnectionImpl.cpp:305:    logModuleInfo = PR_NewLogModule("signaling");
backlog: --- → tech-debt
Mentor: erahm
Whiteboard: [lang=c++][good first bug]
Hi Eric,

Can you assign this bug to me?  

Thank you,

Raulie
(In reply to Raulie Raulerson from comment #1)
> Hi Eric,
> 
> Can you assign this bug to me?  
> 
> Thank you,
> 
> Raulie

Assigned! Let me know if you have any questions, the parent bug 1219461, comment 0 provides a bit more detail on the conversion if that helps.
Assignee: nobody → hhraulerson
I am not certain if I am doing this right.  Below is my replacement of the GetWebRTCLogInfo() method:

static LazyLogModule gWebRTCLogModule = nullptr;

LazyLogModule GetWebRTCLogInfo()
{
  if (gWebRTCLogModule == nullptr)
    gWebRTCLogModule = new LazyLogModule("webrtc_trace");

  return gWebRTCLogModule;
}

I don't want to alter or remove any existing methods as they could be called by other classes.  Is the call to the LazyLogModule constructor correct or do I just need to do the following in the if statement:

gWebRTCLogModule("webrtc_trace");

Thanks.
Good question. A quick search on dxr [1] indicates this function is never used. As part of this cleanup you can just delete it and the static variable completely.

For other cases where the function is only used locally you can follow the suggestion from the parent bug:

File Scoped Getter Function
===========================
> PR_LogModuleInfo* GetFooLogger() {
>  static (s|g)?(F|f)ooLogger = nullptr;
>  if (!fooLogger) fooLogger = PR_NewLog("FooLogger");
>  return fooLogger;
> }
> ...
> void blah() { MOZ_LOG(GetFooLogger(), ...); }

This would become:
> static LazyLogModule sFooLogger("FooLogger");
> ...
> void blah() { MOZ_LOG(sFooLogger, ...); }

Let me know if you have any other questions!

[1] https://dxr.mozilla.org/mozilla-central/search?q=GetWebRTCLogInfo&case=true
I am sure there are deficiencies in the attached patch file.  I was unsure what to do when existing functions were called locally in the source code files you mentioned and a reference to a LogModule was used to perform a function.  For example, in WebRtcLog.cpp, the method CheckOverrides uses a pointer to a PRLogModuleInfo object.  I subsequently replaced that call with "LazyLogModule *log_info = GetWebRtcTraceLog();".  The GetWebRtcTraceLog method returns a reference to a LazyLogModule instead of a PRLogModuleInfo reference.  

Not sure if this is the proper way to do things.  Please let me know where any changes are needed.  Thanks!!
Attachment #8731935 - Flags: review?(erahm)
Comment on attachment 8731935 [details] [diff] [review]
bug1219468_replacePRLogModuleInfo.diff

Review of attachment 8731935 [details] [diff] [review]:
-----------------------------------------------------------------

This is a great start, I've made a few comments below. Also it looks like unfortunately we won't be able to convert a few of these due to how they are used.

For the next iteration can you please try building before posting your patches?

::: media/webrtc/signaling/src/common/browser_logging/CSFLog.cpp
@@ +20,2 @@
>  
> +LazyLogModule *GetSignalingLogInfo()

This function is never used, we can just remove it here and in the header.

::: media/webrtc/signaling/src/common/browser_logging/CSFLog.h
@@ +39,5 @@
>  ;
>  
>  void CSFLogV( CSFLogLevel priority, const char* sourceFile, int sourceLine, const char* tag , const char* format, va_list args);
>  
> +struct LazyLogModule *GetSignalingLogInfo();

This can be removed too.

::: media/webrtc/signaling/src/common/browser_logging/WebRtcLog.cpp
@@ -32,5 @@
>  #else // Assume a POSIX environment
>  NS_NAMED_LITERAL_CSTRING(default_log_name, "WebRTC.log");
>  #endif
>  
> -static PRLogModuleInfo* GetWebRtcTraceLog()

I think unfortunately we can't convert this one, I'll double-check with a member of the media team.

@@ -42,4 @@
>    return sLog;
>  }
>  
> -static PRLogModuleInfo* GetWebRtcAECLog()

Same here.

::: media/webrtc/signaling/src/media-conduit/WebrtcGmpVideoCodec.cpp
@@ -34,5 @@
>  #ifdef MOZILLA_INTERNAL_API
>  extern mozilla::LogModule* GetGMPLog();
>  #else
>  // For CPP unit tests
> -PRLogModuleInfo*

It looks like this needs to remain the same for now.

::: media/webrtc/signaling/src/peerconnection/PeerConnectionImpl.cpp
@@ +307,5 @@
>  }
>  
>  class nsIDOMDataChannel;
>  
> +LazyLogModule *signalingLogInfo() {

Lets just replace this whole function with a static variable, ie: 

> static LazyLogModule sSignalingLogInfo("signaling");

And then update any references to the function to just use the variable directly.
Attachment #8731935 - Flags: review?(erahm) → feedback+
:jesup it looks like |GetWebRtcTraceLog| and |GetWebRtcAECLog| are used to set some sort of mask [1]. Do you know if these are using legit log levels (Disabled - Verbose) or is it arbitrary value?

[1] https://dxr.mozilla.org/mozilla-central/rev/3e04659fdf6aef792f7cf9840189c6c38d08d1e8/media/webrtc/signaling/src/common/browser_logging/WebRtcLog.cpp#85-94
Flags: needinfo?(rjesup)
(In reply to Eric Rahm [:erahm] from comment #7)
> :jesup it looks like |GetWebRtcTraceLog| and |GetWebRtcAECLog| are used to
> set some sort of mask [1]. Do you know if these are using legit log levels
> (Disabled - Verbose) or is it arbitrary value?

webrtc_trace is in fact a mask that's passed down to an internal WebRTC.org-specific logging code that we need a control surface for.  We have a separate env var for where those internal logs go, with "nspr" porting those realtime log messages to NSPR logs (at a perf penalty).

AEC logs are basically a flag to turn on AEC dumping of data
Flags: needinfo?(rjesup)
(In reply to Eric Rahm [:erahm] from comment #6)
> Comment on attachment 8731935 [details] [diff] [review]
> bug1219468_replacePRLogModuleInfo.diff
> 
> Review of attachment 8731935 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> This is a great start, I've made a few comments below. Also it looks like
> unfortunately we won't be able to convert a few of these due to how they are
> used.
> 
> For the next iteration can you please try building before posting your
> patches?
> 
> ::: media/webrtc/signaling/src/common/browser_logging/CSFLog.cpp
> @@ +20,2 @@
> >  
> > +LazyLogModule *GetSignalingLogInfo()
> 
> This function is never used, we can just remove it here and in the header.
> 
> ::: media/webrtc/signaling/src/common/browser_logging/CSFLog.h
> @@ +39,5 @@
> >  ;
> >  
> >  void CSFLogV( CSFLogLevel priority, const char* sourceFile, int sourceLine, const char* tag , const char* format, va_list args);
> >  
> > +struct LazyLogModule *GetSignalingLogInfo();
> 
> This can be removed too.
> 
> ::: media/webrtc/signaling/src/common/browser_logging/WebRtcLog.cpp
> @@ -32,5 @@
> >  #else // Assume a POSIX environment
> >  NS_NAMED_LITERAL_CSTRING(default_log_name, "WebRTC.log");
> >  #endif
> >  
> > -static PRLogModuleInfo* GetWebRtcTraceLog()
> 
> I think unfortunately we can't convert this one, I'll double-check with a
> member of the media team.
> 
> @@ -42,4 @@
> >    return sLog;
> >  }
> >  
> > -static PRLogModuleInfo* GetWebRtcAECLog()
> 
> Same here.
> 
> ::: media/webrtc/signaling/src/media-conduit/WebrtcGmpVideoCodec.cpp
> @@ -34,5 @@
> >  #ifdef MOZILLA_INTERNAL_API
> >  extern mozilla::LogModule* GetGMPLog();
> >  #else
> >  // For CPP unit tests
> > -PRLogModuleInfo*
> 
> It looks like this needs to remain the same for now.
> 
> ::: media/webrtc/signaling/src/peerconnection/PeerConnectionImpl.cpp
> @@ +307,5 @@
> >  }
> >  
> >  class nsIDOMDataChannel;
> >  
> > +LazyLogModule *signalingLogInfo() {
> 
> Lets just replace this whole function with a static variable, ie: 
> 
> > static LazyLogModule sSignalingLogInfo("signaling");
> 
> And then update any references to the function to just use the variable
> directly.

Thank you for the comments.  I am working on addressing the issues you noted. 

I am running into the following errors when I build the changes:

Undefined symbols for architecture x86_64:
      "mozilla::detail::log_print(mozilla::LogModule const*, mozilla::LogLevel, char const*, ...)", referenced from:
        _CSFLogV in CSFLog.o

      "mozilla::LogModule::Get(char const*)", referenced from:
        _CSFLogV in CSFLog.o

ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I will try to straighten this out tomorrow, but may ask for help if I get stuck.

Thanks.
> 
> Thank you for the comments.  I am working on addressing the issues you
> noted. 
> 
> I am running into the following errors when I build the changes:
> 
> Undefined symbols for architecture x86_64:
>       "mozilla::detail::log_print(mozilla::LogModule const*,
> mozilla::LogLevel, char const*, ...)", referenced from:
>         _CSFLogV in CSFLog.o
> 
>       "mozilla::LogModule::Get(char const*)", referenced from:
>         _CSFLogV in CSFLog.o
> 
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> 
> I will try to straighten this out tomorrow, but may ask for help if I get
> stuck.
> 
> Thanks.

I haven't been able to figure out why I am still getting for the errors above.  The best I can figure is that the call to MOZ_LOG is causing the issue in CSFLog.cpp (and consequently CSFLog.o).  I am assuming it's because MOZ_LOG, mozilla::detail::log_print, and MOZ_LOG_TEST all expect pointers to a LogModule instead of the object itself (passed by value).  That's why the compiler cannot match the existing function headers with the call from MOZ_LOG.  

Do you have any recommendations on how to deal with this issue?
Flags: needinfo?(erahm)
Attached file CSFLog.cpp (obsolete) —
Attached are the changes to CSFLog.cpp that are causing build errors.
Attachment #8731935 - Attachment is obsolete: true
 > I haven't been able to figure out why I am still getting for the errors
> above.  The best I can figure is that the call to MOZ_LOG is causing the
> issue in CSFLog.cpp (and consequently CSFLog.o).  I am assuming it's because
> MOZ_LOG, mozilla::detail::log_print, and MOZ_LOG_TEST all expect pointers to
> a LogModule instead of the object itself (passed by value).  That's why the
> compiler cannot match the existing function headers with the call from
> MOZ_LOG.  
> 
> Do you have any recommendations on how to deal with this issue?

Ugh this has been a bit more complicated than I had hoped. It looks like the issue is that this code is used in the signaling unit tests [1] which don't link with libxul (that's where mozilla::LazyLogModule lives). I filed bug 1257713 to fix the unit tests, but for now we can just leave the "signaling" log as-is.

[1] Running |./mach build -j1 binaries| (limiting our build system to one thing at a time) helped me identify that it was during the building of a unit test that it failed.
Flags: needinfo?(erahm)
(In reply to Eric Rahm [:erahm] from comment #6
> > -static PRLogModuleInfo* GetWebRtcAECLog()
> 
> Same here. 

It looks like we *can* change this one given :jesup's response in comment 8.
(In reply to Eric Rahm [:erahm] from comment #12)
>  > I haven't been able to figure out why I am still getting for the errors
> > above.  The best I can figure is that the call to MOZ_LOG is causing the
> > issue in CSFLog.cpp (and consequently CSFLog.o).  I am assuming it's because
> > MOZ_LOG, mozilla::detail::log_print, and MOZ_LOG_TEST all expect pointers to
> > a LogModule instead of the object itself (passed by value).  That's why the
> > compiler cannot match the existing function headers with the call from
> > MOZ_LOG.  
> > 
> > Do you have any recommendations on how to deal with this issue?
> 
> Ugh this has been a bit more complicated than I had hoped. It looks like the
> issue is that this code is used in the signaling unit tests [1] which don't
> link with libxul (that's where mozilla::LazyLogModule lives). I filed bug
> 1257713 to fix the unit tests, but for now we can just leave the "signaling"
> log as-is.
> 
> [1] Running |./mach build -j1 binaries| (limiting our build system to one
> thing at a time) helped me identify that it was during the building of a
> unit test that it failed.

Does this mean that CSFLog.h and CSFLog.cpp need to remain the same for now and all other file changes can proceed?
(In reply to Raulie Raulerson from comment #14)
> (In reply to Eric Rahm [:erahm] from comment #12)
> >  > I haven't been able to figure out why I am still getting for the errors
> > > above.  The best I can figure is that the call to MOZ_LOG is causing the
> > > issue in CSFLog.cpp (and consequently CSFLog.o).  I am assuming it's because
> > > MOZ_LOG, mozilla::detail::log_print, and MOZ_LOG_TEST all expect pointers to
> > > a LogModule instead of the object itself (passed by value).  That's why the
> > > compiler cannot match the existing function headers with the call from
> > > MOZ_LOG.  
> > > 
> > > Do you have any recommendations on how to deal with this issue?
> > 
> > Ugh this has been a bit more complicated than I had hoped. It looks like the
> > issue is that this code is used in the signaling unit tests [1] which don't
> > link with libxul (that's where mozilla::LazyLogModule lives). I filed bug
> > 1257713 to fix the unit tests, but for now we can just leave the "signaling"
> > log as-is.
> > 
> > [1] Running |./mach build -j1 binaries| (limiting our build system to one
> > thing at a time) helped me identify that it was during the building of a
> > unit test that it failed.
> 
> Does this mean that CSFLog.h and CSFLog.cpp need to remain the same for now
> and all other file changes can proceed?

I think you can still remove |gWebRTCLogModuleInfo| and |GetWebRTCLogInfo()| [1] as they are unused.

[1] https://dxr.mozilla.org/mozilla-central/rev/f14898695ee0dd14615914f3e1401f17df57fdd7/media/webrtc/signaling/src/common/browser_logging/CSFLog.cpp#29-37
I am still working on this bug.  I just ran into some problems with my Mozilla setup.  Hope to have a patch committed in the next few days.
(In reply to Raulie Raulerson from comment #16)
> I am still working on this bug.  I just ran into some problems with my
> Mozilla setup.  Hope to have a patch committed in the next few days.

Thanks for the update, let me know if you have any questions. Our IRC server [1] can be a useful resource for getting started, feel free to hop on there if you need any assistance.

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Introduction#Need_help
I have made all changes except to ./media/mtransport/logging.h (this creates more errors and I need .  The changes I have made will be posted as a patch, though I know I still have some work to do.  When I try to build with these changes, I get the error below:

../../../mtransport/testlib/transportlayerprsock.o

 Undefined symbols for architecture x86_64:
   "mozilla::LogModule::Get(char const*)", referenced from:
        CheckOverrides(unsigned int*, nsACString*, bool*) in Unified_cpp_webrtc_signaling0.o

    ld: symbol(s) not found for architecture x86_64 
    clang: error: linker command failed with exit code 1 (use -v to see invocation)
    make[2]: *** [sdp_unittests] Error 1
    make[1]: *** [media/webrtc/signaling/test/target] Error 2
    make: *** [binaries] Error 2

Can you provide any insight on how I might be able to fix this error?  I haven't had much luck in determining why mozilla::LogModule::Get() is being called from CheckOverrides().  Any help you could provide would be greatly appreciated.
Attachment #8732565 - Attachment is obsolete: true
Flags: needinfo?(erahm)
(In reply to Raulie Raulerson from comment #18)
> Created attachment 8736082 [details] [diff] [review]
> bug1219468_replacePRLogModuleInfo.diff
> 
> I have made all changes except to ./media/mtransport/logging.h (this creates
> more errors and I need .  The changes I have made will be posted as a patch,
> though I know I still have some work to do.  When I try to build with these
> changes, I get the error below:
> 
> ../../../mtransport/testlib/transportlayerprsock.o
> 
>  Undefined symbols for architecture x86_64:
>    "mozilla::LogModule::Get(char const*)", referenced from:
>         CheckOverrides(unsigned int*, nsACString*, bool*) in
> Unified_cpp_webrtc_signaling0.o
> 
>     ld: symbol(s) not found for architecture x86_64 
>     clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
>     make[2]: *** [sdp_unittests] Error 1
>     make[1]: *** [media/webrtc/signaling/test/target] Error 2
>     make: *** [binaries] Error 2
> 
> Can you provide any insight on how I might be able to fix this error?  I
> haven't had much luck in determining why mozilla::LogModule::Get() is being
> called from CheckOverrides().  Any help you could provide would be greatly
> appreciated.

This is good progress, let's just leave GetWebRtcAECLog() as-is for now, it can be fixed when we fix the signaling unit tests.
Flags: needinfo?(erahm)
(In reply to Eric Rahm [:erahm] from comment #19)
> (In reply to Raulie Raulerson from comment #18)
> > Created attachment 8736082 [details] [diff] [review]
> > bug1219468_replacePRLogModuleInfo.diff
> > 
> > I have made all changes except to ./media/mtransport/logging.h (this creates
> > more errors and I need .  The changes I have made will be posted as a patch,
> > though I know I still have some work to do.  When I try to build with these
> > changes, I get the error below:
> > 
> > ../../../mtransport/testlib/transportlayerprsock.o
> > 
> >  Undefined symbols for architecture x86_64:
> >    "mozilla::LogModule::Get(char const*)", referenced from:
> >         CheckOverrides(unsigned int*, nsACString*, bool*) in
> > Unified_cpp_webrtc_signaling0.o
> > 
> >     ld: symbol(s) not found for architecture x86_64 
> >     clang: error: linker command failed with exit code 1 (use -v to see
> > invocation)
> >     make[2]: *** [sdp_unittests] Error 1
> >     make[1]: *** [media/webrtc/signaling/test/target] Error 2
> >     make: *** [binaries] Error 2
> > 
> > Can you provide any insight on how I might be able to fix this error?  I
> > haven't had much luck in determining why mozilla::LogModule::Get() is being
> > called from CheckOverrides().  Any help you could provide would be greatly
> > appreciated.
> 
> This is good progress, let's just leave GetWebRtcAECLog() as-is for now, it
> can be fixed when we fix the signaling unit tests.

I left GetWebRtcAECLog() as it is for now.  I keep running into an error very similar to the ones I have previously posted about. This time it has to do with PeerConnectionImpl.cpp (please note that I have not altered ./media/mtransport/logging.h yet -- I have tried, but I get similar errors; for now, I am trying to fix each error when I encounter it).  Again, the error manifests itself when executing the signaling unit tests:

0:25.98 Undefined symbols for architecture x86_64:
 0:25.98   "mozilla::LogModule::Get(char const*)", referenced from:
 0:25.98       mozilla::PeerConnectionImpl::PeerConnectionImpl(mozilla::dom::GlobalObject const*) in PeerConnectionImpl.o
 0:25.99 ld: symbol(s) not found for architecture x86_64
 0:25.99 clang: error: linker command failed with exit code 1 (use -v to see invocation)
 0:25.99 make[2]: *** [signaling_unittests] Error 1
 0:25.99 make[1]: *** [media/webrtc/signaling/test/target] Error 2
 0:25.99 make: *** [binaries] Error 2

Should I wait to resume working on this bug until the signaling tests are fixed?  Thank you for being patient with me.
Have the signaling unit tests been fixed?  I would like to resolve this bug if possible.
Flags: needinfo?(erahm)
Hi Raulie,

I don't see the signaling unit tests being broken for compilation, which I understand is the problem you are facing. So they compile fine for me without your change. So I'm guessing this is caused by your patch then.
Note: the signaling_unittest does not start for me right now, but looks like a different error to me.

My guess is that the problem arises from the fact the unit tests under mtransport link in big parts of XUL.
Rank: 35
Priority: -- → P3
Status: NEW → ASSIGNED
Nils the issue mentioned is from comment 12. The signaling unit tests are still standalone so using mozlog is problematic.
(In reply to Eric Rahm [:erahm] from comment #23)
> Nils the issue mentioned is from comment 12. The signaling unit tests are
> still standalone so using mozlog is problematic.

Thanks for the response Eric and Nils.  Sounds like I will have to wait for the signaling unit tests to be converted before this bug can be resolved.  Please let me know if I misinterpreted your comments.  Thanks!
Flags: needinfo?(erahm)
Depends on: 1257713
Depends on: 1316611
Eric, have the signaling unit tests been fixed?  I would like to try to resolve this bug, but am aware that I will have a difficult time doing so until the signaling unit tests are fixed.  Thanks!
Raulie as you can see in bug 1316611 there was some progress made in other bugs. But I think it is not totally resolved yet.
Until bug 1316611 is fixed, can't we just do:
#if MOZILLA_INTERNAL_API
  use LazyLog
#else
  use PR_NewLogModule
#endif
Attachment #8736082 - Attachment is obsolete: true
Extends the previous patch to remove the rest of the PRLogModuleInfos except when building c++ unit tests.  Also fixes that webrtc.org LOG(...) << ... usages were going to stderr in Debug builds - now they go to nspr (and in Debug builds, they still also go to stderr).  MOZ_LOG logging levels are now translated to webrtc trace masks with 5 (verbose) mapping to 65535, the most commonly-used webrtc trace value.  The mapping can be overridden by a env var.
Attachment #8831040 - Flags: review?(na-g)
Attachment #8831040 - Flags: review?(erahm)
one minor change I forgot to save
Attachment #8831041 - Flags: review?(na-g)
Attachment #8831041 - Flags: review?(erahm)
Attachment #8831040 - Attachment is obsolete: true
Attachment #8831040 - Flags: review?(na-g)
Attachment #8831040 - Flags: review?(erahm)
Comment on attachment 8831041 [details] [diff] [review]
Remove the rest of the non-LazyLogModules in webrtc, except for cppunit tests

Review of attachment 8831041 [details] [diff] [review]:
-----------------------------------------------------------------

Great to see this finally getting wrapped up!
Attachment #8831041 - Flags: review?(erahm) → review+
Comment on attachment 8831041 [details] [diff] [review]
Remove the rest of the non-LazyLogModules in webrtc, except for cppunit tests

Review of attachment 8831041 [details] [diff] [review]:
-----------------------------------------------------------------

Looks great.
Attachment #8831041 - Flags: review?(na-g) → review+
Pushed by rjesup@wgate.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/1a2aba1ecb3c
Replace PRLogModuleInfo usage with LazyLogModule in webrtc r=jesup
https://hg.mozilla.org/integration/mozilla-inbound/rev/a83751c7946f
Remove the rest of the non-LazyLogModules in webrtc, except for cppunit tests r=erahm,ng
https://hg.mozilla.org/mozilla-central/rev/1a2aba1ecb3c
https://hg.mozilla.org/mozilla-central/rev/a83751c7946f
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
You need to log in before you can comment on or make changes to this bug.