Closed Bug 1341180 Opened 8 years ago Closed 8 years ago

Issue on accessing resolution of print settings on Linux

Categories

(Core :: Widget: Gtk, defect, P2)

45 Branch
Unspecified
Linux
defect

Tracking

()

RESOLVED WONTFIX

People

(Reporter: lochang, Assigned: lochang)

Details

(Whiteboard: tpi:+)

No description provided.
Can not access resolution of print settings through XPCOM |showPrintDialog|.
Sorry for the late reply. Let's move the discussion here. > Why is this a problem? Can the error be caught by the caller? > What is the call stack? The error code I got in javascript runtime is: JavaScript error: x-bogus://XPConnect/Sandbox -> resource://ppapipdf.js/ppapi-content-sandbox.js, line 113: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIPrintSettings.resolution] I am now getting print settings by calling |showPrintDialog| in one process and pass it to another process to ask for PDF file with specific print settings from PDFium binary. Though i don't really need the resolution, it will somehow call |getResolution| when I pass the print settings from one process to another process. > I think it is better if the lack of a specific resolution is detectable... > ...and throwing an error as done in the code here seems a reasonable way to > indicate that there is no specified resolution. I understand that it is reasonable to throw an error here. But what I am suggesting is to add a default value for resolution so that we can get resolution of print settings from |showPrintDialog| normally. Or maybe there are better ways to fix this, do you have any suggestion? > Note that this code was added for the GTK port and so I guess this method > throws an error on other platforms anyway. I am not sure what you mean here. But I have tested my patch of getting print settings through |showPrintDialog| also on Mac and Windows, and they work normally. And it seems that on Mac it will call to nsPrintSettings:GetResolution in nsPrintSettingsImpl.cpp [1] which just assign the existing resolution and return NS_OK. [1] http://searchfox.org/mozilla-central/source/widget/nsPrintSettingsImpl.cpp#171
Flags: needinfo?(karlt)
(In reply to Louis Chang [:lochang] from comment #2) > > Note that this code was added for the GTK port and so I guess this method > > throws an error on other platforms anyway. > > I am not sure what you mean here. But I have tested my patch of getting > print settings through |showPrintDialog| also on Mac and Windows, and they > work normally. And it seems that on Mac it will call to > nsPrintSettings:GetResolution in nsPrintSettingsImpl.cpp [1] which just > assign the existing resolution and return NS_OK. > > [1] > http://searchfox.org/mozilla-central/source/widget/nsPrintSettingsImpl.cpp#171 Ah, yes, you are right. I was looking at the wrong code. This was added in https://hg.mozilla.org/mozilla-central/rev/2bb26d742f5f It won't throw an error on Mac and WINNT, but it probably doesn't do anything useful either.
(In reply to Louis Chang [:lochang] from comment #2) > Sorry for the late reply. Let's move the discussion here. > > > Why is this a problem? Can the error be caught by the caller? > > What is the call stack? > > The error code I got in javascript runtime is: > JavaScript error: x-bogus://XPConnect/Sandbox -> > resource://ppapipdf.js/ppapi-content-sandbox.js, line 113: NS_ERROR_FAILURE: > Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) > [nsIPrintSettings.resolution] > > I am now getting print settings by calling |showPrintDialog| in one process > and pass it to another process to ask for PDF file with specific print > settings from PDFium binary. Though i don't really need the resolution, it > will somehow call |getResolution| when I pass the print settings from one > process to another process. The key to resolving this issue is to find the code accessing nsIPrintSettings.resolution. DumpJSStack() may be helpful, if the developer tools are not. > > I think it is better if the lack of a specific resolution is detectable... > > ...and throwing an error as done in the code here seems a reasonable way to > > indicate that there is no specified resolution. > > I understand that it is reasonable to throw an error here. But what I am > suggesting is to add a default value for resolution so that we can get > resolution of print settings from |showPrintDialog| normally. Adding a default value is not what we want. We want to know whether there is a resolution set or not. e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=539427#c14 > Or maybe there > are better ways to fix this, do you have any suggestion? Yes. Change the caller to catch the error.
Flags: needinfo?(karlt)
> The key to resolving this issue is to find the code accessing > nsIPrintSettings.resolution. > > DumpJSStack() may be helpful, if the developer tools are not. So it seems like that when passing an object from one process through ipc to another process will automatically run through all the getter of the class. And unfortunately, that's the place access the nsIPrintSettings.resolution... By the way, if Linux print dialog doesn't provide a way for user to set resolution (if I don't misunderstand anything), do we really need to check if resolution is existed? Or do we even need this attribute? (Or maybe just don't override it like in other platforms) The call stack is as below: #0 nsPrintSettingsGTK::GetResolution (this=0x7f299cfa40a0, aResolution=0x7ffd0e7f29a0) at /home/ghoo1125/FirefoxOS/m-inbound/widget/gtk/nsPrintSettingsGTK.cpp:795 #1 0x00007f29bdd5ccc6 in NS_InvokeByIndex () at /home/ghoo1125/FirefoxOS/m-inbound/xpcom/reflect/xptcall/md/unix/xptcinvoke_asm_x86_64_unix.S:88 #2 0x00007f29be599949 in Invoke (this=0x7ffd0e7f2958) at /home/ghoo1125/FirefoxOS/m-inbound/js/xpconnect/src/XPCWrappedNative.cpp:2064 #3 CallMethodHelper::Call (this=0x7ffd0e7f2958) at /home/ghoo1125/FirefoxOS/m-inbound/js/xpconnect/src/XPCWrappedNative.cpp:1383 #4 0x00007f29be58861f in XPCWrappedNative::CallMethod (ccx=..., mode=mode@entry=XPCWrappedNative::CALL_GETTER) at /home/ghoo1125/FirefoxOS/m-inbound/js/xpconnect/src/XPCWrappedNative.cpp:1350 #5 0x00007f29be58d257 in GetAttribute (ccx=...) at /home/ghoo1125/FirefoxOS/m-inbound/js/xpconnect/src/xpcprivate.h:1877 #6 XPC_WN_GetterSetter (cx=0x7f29adff5000, argc=<optimized out>, vp=<optimized out>) at /home/ghoo1125/FirefoxOS/m-inbound/js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1179 #7 0x00007f29c11459cd in js::CallJSNative (cx=0x7f29adff5000, native=0x7f29be58cff7 <XPC_WN_GetterSetter(JSContext*, unsigned int, JS::Value*)>, args=...) at /home/ghoo1125/FirefoxOS/m-inbound/js/src/jscntxtinlines.h:239 #8 0x00007f29c1139f4f in js::InternalCallOrConstruct (cx=cx@entry=0x7f29adff5000, args=..., construct=construct@entry=js::NO_CONSTRUCT) at /home/ghoo1125/FirefoxOS/m-inbound/js/src/vm/Interpreter.cpp:459 #9 0x00007f29c113a32d in InternalCall (cx=cx@entry=0x7f29adff5000, args=...) at /home/ghoo1125/FirefoxOS/m-inbound/js/src/vm/Interpreter.cpp:504 #10 0x00007f29c113a4be in js::Call (cx=cx@entry=0x7f29adff5000, fval=..., fval@entry=..., thisv=..., thisv@entry=..., args=..., rval=..., rval@entry=...) at /home/ghoo1125/FirefoxOS/m-inbound/js/src/vm/Interpreter.cpp:523 #11 0x00007f29c113a5bc in js::CallGetter (cx=0x7f29adff5000, thisv=..., thisv@entry=..., getter=getter@entry=..., rval=rval@entry=...) at /home/ghoo1125/FirefoxOS/m-inbound/js/src/vm/Interpreter.cpp:637 #12 0x00007f29c113a89b in CallGetter (vp=..., shape=..., receiver=..., obj=..., cx=0x7f29adff5000) at /home/ghoo1125/FirefoxOS/m-inbound/js/src/vm/NativeObject.cpp:1809 #13 GetExistingProperty<(js::AllowGC)1> (cx=0x7f29adff5000, receiver=..., obj=..., shape=..., vp=...) at /home/ghoo1125/FirefoxOS/m-inbound/js/src/vm/NativeObject.cpp:1861 #14 0x00007f29c113e836 in NativeGetPropertyInline<(js::AllowGC)1> (cx=cx@entry=0x7f29adff5000, obj=..., receiver=..., id=..., nameLookup=nameLookup@entry=NotNameLookup, vp=...) at /home/ghoo1125/FirefoxOS/m-inbound/js/src/vm/NativeObject.cpp:2084 #15 0x00007f29c113eee0 in js::NativeGetProperty (cx=cx@entry=0x7f29adff5000, obj=..., obj@entry=..., receiver=..., id=..., id@entry=..., vp=..., vp@entry=...) at /home/ghoo1125/FirefoxOS/m-inbound/js/src/vm/NativeObject.cpp:2118 #16 0x00007f29c0b0fc77 in GetProperty (vp=..., id=..., receiver=..., obj=..., cx=0x7f29adff5000) at /home/ghoo1125/FirefoxOS/m-inbound/js/src/vm/NativeObject.h:1523 #17 js::GetProperty (cx=0x7f29adff5000, obj=..., receiver=..., id=..., vp=...) at /home/ghoo1125/FirefoxOS/m-inbound/js/src/jsobj.h:854 #18 0x00007f29c0f9ad4a in JO (scx=0x7ffd0e7f3440, obj=..., cx=0x7f29adff5000) at /home/ghoo1125/FirefoxOS/m-inbound/js/src/json.cpp:400 #19 Str (cx=0x7f29adff5000, v=..., scx=scx@entry=0x7ffd0e7f3440) at /home/ghoo1125/FirefoxOS/m-inbound/js/src/json.cpp:591 #20 0x00007f29c0f9cd43 in js::Stringify (cx=cx@entry=0x7f29adff5000, vp=..., vp@entry=..., replacer_=<optimized out>, space_=..., sb=..., stringifyBehavior=stringifyBehavior@entry=js::Normal) at /home/ghoo1125/FirefoxOS/m-inbound/js/src/json.cpp:758 #21 0x00007f29c0ee2e88 in JS_Stringify (cx=0x7f29adff5000, vp=..., vp@entry=..., replacer=replacer@entry=..., space=..., callback=callback@entry=0x7f29bea0fbff <JSONCreator(char16_t const*, uint32_t, void*)>, data=data@entry=0x7ffd0e7f3820) at /home/ghoo1125/FirefoxOS/m-inbound/js/src/jsapi.cpp:5465 #22 0x00007f29bea13810 in GetParamsForMessage (aCx=0x7f29adff5000, aValue=..., aTransfer=..., aData=...) at /home/ghoo1125/FirefoxOS/m-inbound/dom/base/nsFrameMessageManager.cpp:659 #23 0x00007f29bea14069 in nsFrameMessageManager::DispatchAsyncMessage (this=0x7f29b384fd40, aMessageName=..., aJSON=..., aObjects=..., aPrincipal=0x0, aTransfers=..., aCx=0x7f29adff5000, aArgc=2 '\002') at /home/ghoo1125/FirefoxOS/m-inbound/dom/base/nsFrameMessageManager.cpp:843 #24 0x00007f29bdd5ccc6 in NS_InvokeByIndex () at /home/ghoo1125/FirefoxOS/m-inbound/xpcom/reflect/xptcall/md/unix/xptcinvoke_asm_x86_64_unix.S:88 #25 0x00007f29be599949 in Invoke (this=0x7ffd0e7f3b28) at /home/ghoo1125/FirefoxOS/m-inbound/js/xpconnect/src/XPCWrappedNative.cpp:2064 #26 CallMethodHelper::Call (this=0x7ffd0e7f3b28) at /home/ghoo1125/FirefoxOS/m-inbound/js/xpconnect/src/XPCWrappedNative.cpp:1383 #27 0x00007f29be58861f in XPCWrappedNative::CallMethod (ccx=..., mode=mode@entry=XPCWrappedNative::CALL_METHOD) ---Type <return> to continue, or q <return> to quit--- at /home/ghoo1125/FirefoxOS/m-inbound/js/xpconnect/src/XPCWrappedNative.cpp:1350 #28 0x00007f29be58cfc2 in XPC_WN_CallMethod (cx=0x7f29adff5000, argc=<optimized out>, vp=<optimized out>) at /home/ghoo1125/FirefoxOS/m-inbound/js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1143 #29 0x00007f29c11459cd in js::CallJSNative (cx=0x7f29adff5000, native=0x7f29be58cdd2 <XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*)>, args=...) at /home/ghoo1125/FirefoxOS/m-inbound/js/src/jscntxtinlines.h:239 #30 0x00007f29c1139f4f in js::InternalCallOrConstruct (cx=0x7f29adff5000, args=..., construct=js::NO_CONSTRUCT) at /home/ghoo1125/FirefoxOS/m-inbound/js/src/vm/Interpreter.cpp:459 #31 0x00007f29c112c0e2 in CallFromStack (args=..., cx=<optimized out>) at /home/ghoo1125/FirefoxOS/m-inbound/js/src/vm/Interpreter.cpp:510 #32 Interpret (cx=0x7f29adff5000, state=...) at /home/ghoo1125/FirefoxOS/m-inbound/js/src/vm/Interpreter.cpp:2922 #33 0x00007f29c1139c93 in js::RunScript (cx=cx@entry=0x7f29adff5000, state=...) at /home/ghoo1125/FirefoxOS/m-inbound/js/src/vm/Interpreter.cpp:405 #34 0x00007f29c113a16d in js::InternalCallOrConstruct (cx=cx@entry=0x7f29adff5000, args=..., construct=construct@entry=js::NO_CONSTRUCT) at /home/ghoo1125/FirefoxOS/m-inbound/js/src/vm/Interpreter.cpp:477 #35 0x00007f29c113a32d in InternalCall (cx=cx@entry=0x7f29adff5000, args=...) at /home/ghoo1125/FirefoxOS/m-inbound/js/src/vm/Interpreter.cpp:504 #36 0x00007f29c113a4be in js::Call (cx=cx@entry=0x7f29adff5000, fval=..., fval@entry=..., thisv=..., thisv@entry=..., args=..., rval=..., rval@entry=...) at /home/ghoo1125/FirefoxOS/m-inbound/js/src/vm/Interpreter.cpp:523 #37 0x00007f29c0ef09cf in JS_CallFunctionValue (cx=0x7f29adff5000, obj=obj@entry=..., fval=..., fval@entry=..., args=..., rval=..., rval@entry=...) at /home/ghoo1125/FirefoxOS/m-inbound/js/src/jsapi.cpp:2769 #38 0x00007f29bea165e5 in nsFrameMessageManager::ReceiveMessage (this=0x7f29b384fd40, aTarget=0x7f29adf21600, aTargetFrameLoader=0x7f29adf07100, aTargetClosed=<optimized out>, aMessage=..., aIsSync=<optimized out>, aCloneData=0x7ffd0e7f4c48, aCpows=0x7ffd0e7f4c30, aPrincipal=0x0, aRetVal=0x0) at /home/ghoo1125/FirefoxOS/m-inbound/dom/base/nsFrameMessageManager.cpp:1193 #39 0x00007f29bea16b37 in nsFrameMessageManager::ReceiveMessage (this=<optimized out>, aTarget=<optimized out>, aTargetFrameLoader=<optimized out>, aMessage=..., aIsSync=<optimized out>, aCloneData=aCloneData@entry=0x7ffd0e7f4c48, aCpows=0x7ffd0e7f4c30, aPrincipal=0x0, aRetVal=0x0) at /home/ghoo1125/FirefoxOS/m-inbound/dom/base/nsFrameMessageManager.cpp:1002 #40 0x00007f29bf93fd92 in mozilla::dom::TabParent::ReceiveMessage (this=this@entry=0x7f299c557000, aMessage=..., aSync=aSync@entry=false, aData=aData@entry=0x7ffd0e7f4c48, aCpows=aCpows@entry=0x7ffd0e7f4c30, aPrincipal=0x0, aRetVal=0x0) at /home/ghoo1125/FirefoxOS/m-inbound/dom/ipc/TabParent.cpp:2367 #41 0x00007f29bf9402be in mozilla::dom::TabParent::RecvAsyncMessage(nsString const&, nsTArray<mozilla::jsipc::CpowEntry>&&, IPC::Principal const&, mozilla::dom::ClonedMessageData const&) (this=0x7f299c557000, aMessage=..., aCpows=<unknown type in /home/ghoo1125/FirefoxOS/m-inbound/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so, CU 0x12c1c7c0, DIE 0x12d55df4>, aPrincipal=..., aData=...) at /home/ghoo1125/FirefoxOS/m-inbound/dom/ipc/TabParent.cpp:1530 #42 0x00007f29be405b87 in mozilla::dom::PBrowserParent::OnMessageReceived (this=<optimized out>, msg__=...) at /home/ghoo1125/FirefoxOS/m-inbound/obj-x86_64-pc-linux-gnu/ipc/ipdl/PBrowserParent.cpp:1801 #43 0x00007f29be196eb1 in mozilla::ipc::MessageChannel::DispatchAsyncMessage (this=0x7f299c5980a8, aMsg=...) at /home/ghoo1125/FirefoxOS/m-inbound/ipc/glue/MessageChannel.cpp:1743 #44 0x00007f29be1a22cf in mozilla::ipc::MessageChannel::DispatchMessage(IPC::Message&&) (this=this@entry=0x7f299c5980a8, aMsg=aMsg@entry=<unknown type in /home/ghoo1125/FirefoxOS/m-inbound/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so, CU 0x29cfbfc, DIE 0x2aa65ab>) at /home/ghoo1125/FirefoxOS/m-inbound/ipc/glue/MessageChannel.cpp:1681 #45 0x00007f29be1a4458 in mozilla::ipc::MessageChannel::RunMessage (this=0x7f299c5980a8, aTask=...) at /home/ghoo1125/FirefoxOS/m-inbound/ipc/glue/MessageChannel.cpp:1572 #46 0x00007f29be1a45f5 in mozilla::ipc::MessageChannel::MessageTask::Run (this=0x7f299eb31050) at /home/ghoo1125/FirefoxOS/m-inbound/ipc/glue/MessageChannel.cpp:1597 #47 0x00007f29bdd4b01f in nsThread::ProcessNextEvent (this=0x7f29b38b6460, aMayWait=<optimized out>, aResult=0x7ffd0e7f520f) at /home/ghoo1125/FirefoxOS/m-inbound/xpcom/threads/nsThread.cpp:1213 #48 0x00007f29bdd7aa22 in NS_ProcessNextEvent (aThread=<optimized out>, aThread@entry=0x7f29b38b6460, aMayWait=aMayWait@entry=false) ---Type <return> to continue, or q <return> to quit--- at /home/ghoo1125/FirefoxOS/m-inbound/xpcom/glue/nsThreadUtils.cpp:361 #49 0x00007f29be198926 in mozilla::ipc::MessagePump::Run (this=0x7f29b384cd80, aDelegate=0x7ffd0e7f5520) at /home/ghoo1125/FirefoxOS/m-inbound/ipc/glue/MessagePump.cpp:96 #50 0x00007f29be1578cb in MessageLoop::RunInternal (this=this@entry=0x7ffd0e7f5520) at /home/ghoo1125/FirefoxOS/m-inbound/ipc/chromium/src/base/message_loop.cc:232 #51 0x00007f29be1578fc in RunHandler (this=0x7ffd0e7f5520) at /home/ghoo1125/FirefoxOS/m-inbound/ipc/chromium/src/base/message_loop.cc:225 #52 MessageLoop::Run (this=0x7ffd0e7f5520) at /home/ghoo1125/FirefoxOS/m-inbound/ipc/chromium/src/base/message_loop.cc:205 #53 0x00007f29bfb2b655 in nsBaseAppShell::Run (this=0x7f29a67b9970) at /home/ghoo1125/FirefoxOS/m-inbound/widget/nsBaseAppShell.cpp:156 #54 0x00007f29c0429699 in XRE_RunAppShell () at /home/ghoo1125/FirefoxOS/m-inbound/toolkit/xre/nsEmbedFunctions.cpp:890 #55 0x00007f29be198a5d in mozilla::ipc::MessagePumpForChildProcess::Run (this=0x7f29b384cd80, aDelegate=0x7ffd0e7f5520) at /home/ghoo1125/FirefoxOS/m-inbound/ipc/glue/MessagePump.cpp:269 #56 0x00007f29be1578cb in MessageLoop::RunInternal (this=this@entry=0x7ffd0e7f5520) at /home/ghoo1125/FirefoxOS/m-inbound/ipc/chromium/src/base/message_loop.cc:232 #57 0x00007f29be1578fc in RunHandler (this=0x7ffd0e7f5520) at /home/ghoo1125/FirefoxOS/m-inbound/ipc/chromium/src/base/message_loop.cc:225 #58 MessageLoop::Run (this=this@entry=0x7ffd0e7f5520) at /home/ghoo1125/FirefoxOS/m-inbound/ipc/chromium/src/base/message_loop.cc:205 #59 0x00007f29c0429c76 in XRE_InitChildProcess (aArgc=<optimized out>, aArgv=<optimized out>, aChildData=<optimized out>) at /home/ghoo1125/FirefoxOS/m-inbound/toolkit/xre/nsEmbedFunctions.cpp:722 #60 0x00000000004050ef in content_process_main (argc=6, argv=0x7ffd0e7f5828) at /home/ghoo1125/FirefoxOS/m-inbound/ipc/app/../contentproc/plugin-container.cpp:197 #61 0x00007f29bc449f45 in __libc_start_main (main=0x404a36 <main(int, char**)>, argc=6, argv=0x7ffd0e7f5828, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffd0e7f5818) at libc-start.c:287 #62 0x0000000000404be9 in _start ()
Flags: needinfo?(karlt)
(In reply to Louis Chang [:lochang] from comment #5) > > The key to resolving this issue is to find the code accessing > > nsIPrintSettings.resolution. > > > > DumpJSStack() may be helpful, if the developer tools are not. > > So it seems like that when passing an object from one process through ipc to > another process will automatically run through all the getter of the class. > And unfortunately, that's the place access the nsIPrintSettings.resolution... I suspect native objects should not in general be sent across processes using JSON. There should be a console message warning about this. Why is that not showing up? http://searchfox.org/mozilla-central/rev/b1044cf7c2000c3e75e8181e893236a940c8b6d2/dom/base/nsFrameMessageManager.cpp#522 See https://bugzilla.mozilla.org/show_bug.cgi?id=1139718#c14 I don't know how this JSON would be interpreted on the other process, but it would not be a proper nsPrintSettingsGTK. I don't know about structured cloning, so I don't know whether or not support for structured cloning could be added. nsIPrintSettingsService::SerializeToPrintData() exists for the purpose of sending print settings to another process, but it is noscript. If you don't actually need a nsPrintSettingsGTK in the other process, then perhaps you can copy out only the info that is needed and pass that to the other process? > By the way, if Linux print dialog doesn't provide a way for user to set > resolution (if I don't misunderstand anything), do we really need to check > if resolution is existed? Or do we even need this attribute? (Or maybe just > don't override it like in other platforms) I assume it was added for a reason. The print dialog differs according to the printer. Some printers have a resolution setting.
Flags: needinfo?(karlt)
> I suspect native objects should not in general be sent across processes using > JSON. There should be a console message warning about this. Why is that > not showing up? > http://searchfox.org/mozilla-central/rev/ > b1044cf7c2000c3e75e8181e893236a940c8b6d2/dom/base/nsFrameMessageManager. > cpp#522 > See https://bugzilla.mozilla.org/show_bug.cgi?id=1139718#c14 > > I don't know how this JSON would be interpreted on the other process, but it > would not be a proper nsPrintSettingsGTK. > > I don't know about structured cloning, so I don't know whether or not support > for structured cloning could be added. First of all, thanks for your kindly replies. I am not sure why it does not print the warning message either... I try to set the breakpoint there but it just did't run through it. But the call stack did show that it is in the call flows. However, it seems that the problem is not in structured cloning, since I comment out the return NS_ERROR_FAILURE in |GetResolution| and i can successfully pass the printsettings to another process (also received correct settings) then generate the PDF file. The problem is simply that it gets a NS_ERROR_FAILURE while accessing resolution where we can do nothing for now. So I would first workaround it by copying out only the info I need.
Priority: -- → P2
Whiteboard: tpi:+
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.