Closed Bug 513048 Opened 15 years ago Closed 15 years ago

[10.6] Firefox Help menu greyed out after waking from sleep if key pressed and "Require password" enabled

Categories

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

Product:
Core
Component:
Widget: Cocoa
Version:
1.9.2 Branch
Platform:
x86
macOS
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
status1.9.2 --- beta3-fixed
status1.9.1 --- ?

People

(Reporter: marcia, Assigned: smichaud)

References

Details

Attachments

(3 files)

Screenshot of Firefox menu showing issue
42.72 KB, image/png
Details
1.9.2 branch patch/workaround
5.72 KB, patch
jaas
: review+
Details | Diff | Splinter Review
Issue with 1.9.1.
30.36 KB, image/jpeg
Details 
Seen using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2a2pre) Gecko/20090827 Namoroka/3.6a2pre as well as a nightly trunk build.

STR:
1. With Namoroka open, put machine to sleep.
2. Wake machine from sleep the next day.
3. Help -> Check for Updates

Result: The entire help menu is greyed out. Changing focus outside the window does not change it. Restarting the browser restores it to the normal state.

I tested a few scenarios where I put the machine to sleep and then woke it a few minutes later, but I was not able to reproduce the bug. I also checked the error console and there is no information in there as well.
Can you try if it is reproducible? Just put it into sleep this afternoon after work and check tomorrow again. Does it only happen for Namoroka? Would be nice to know if Minefield and/or Shiretoko are also affected.
I have not been able to reproduce this consistently. I did notice today that it happened with the latest trunk. As I am looking at the menu, everything is greyed out and an update is waiting to be applied. Both Namoroka, Trunk and Firefox 3.5.2 are all running on this machine.
For me it happens at random per-tab. For some tabs the whole menu is disabled, for some — only several menu items, and for some — all are enabled. Doesn't depend on the site that is loaded in the tab as far as I can get.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a1pre) Gecko/20090908 Minefield/3.7a1pre
Unfortunately this is now happening to me every day using the latest 1.9.2 and trunk nightlies.  When I wake my machine I have to restart both browsers before I check for updates. It is really annoying.
I am happy I came across this bug, I was about to file it on 1.9.1

Marcia, for what it's worth I have been also seeing this problem on 1.9.1

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3

STR:

1. With Firefox open, put machine to sleep
2. Wake machine up
3. Help menu is greyed out
Assignee: nobody → joshmoz
Priority: -- → P2
I think we need to work to get better STR. I know in my case I never shut my laptop off, so I always notice it when I wake my machine from sleep in the AM. The funny thing is it does not always happen, or sometimes it will happen only on 1.9.2 but not on trunk.
Marcia, here's a wild guess -- try my patch for bug 515700:

https://build.mozilla.org/tryserver-builds/smichaud@pobox.com-bugzilla515700-debug-191branch/bugzilla515700-debug-191branch-macosx.dmg

Let us know if you ever see this problem with that tryserver build.
(Following up comment #7)

Oops, I just remembered my tryserver build is on the 1.9.1 branch.  I'll do another one on the trunk and post it at bug 515700 and here.

For the rest of you, only test with the tryserver build from comment #7 if you can reproduce this bug on the 1.9.1 branch (FF 3.5.X or Shiretoko).
Here we have the 'Check for Updates' disabled amongst a seemingly random number of other items disabled and enabled. A user can not check for updates, could be a blocker.

http://imgur.com/YRM1X.png

Screen shot of 1.9.1 (3.5.3) on 10.6
I don't have my 10.6 machine with me here so I cannot check this right away.

I agree with Aaron in Comment 10 that the Check for Updates being disabled is annoying - not sure if it is a blocker but now that it happens with 3.5.x, 3.6 and trunk it certainly has become more consistent.
I think this definitely is a blocker, yes; from my experiences:

 - it is active when you first open the browser (even after you sleep)
 - after a while of usage (as little as 10 minutes) the entire menu is greyed out
 - after a little while more, you see the randomness of comment 10

Can we catch this in a debugger and try to figure out what's going sideways?
Flags: blocking-firefox3.6+
Mike, please try one of the tryserver builds of my patch for bug 515700 (from comment #7 or comment #9).

I think this is likely to be an Apple bug -- a new twist on an old bug that I already worked around on 10.5, but for which my "fix" got disabled on 10.6.
As I noted in the other bug, I will be testing this tryserver build but I probably won't have anything to report back until tomorrow.
Assignee: joshmoz → smichaud
Oddly enough, I have not been seeing this lately on the same 10.6 machine I was seeing it on - using both the latest Minefield and Namoroka nightlies as well as the Firefox 3.6 beta candidate.
How about others who've seen this bug before.  Can you still reproduce
it in current nightlies?

If so, please try one of my tryserver builds from bug 515700 comment
#63.
I can still reproduce in current nightlies on the mozilla-1.9.2 branch. Will try to find time to try the tryserver build later today.
Your tryserver build won't stand up for me on 10.6; keeps crashing on start (no crashserver trace, only shows me the Apple crash reporter)
> only shows me the Apple crash reporter)

Please attach the Apple crash report.
> Please attach the Apple crash report.

Scratch that.  Probably doesn't contain any useful symbols.
> Your tryserver build won't stand up for me on 10.6; keeps crashing
> on start

I can't reproduce this, of course :-(

With any of my three tryserver builds.

Try with a fresh profile.  But please keep a copy of your old profile.

I'd be interested to see if this bug (bug 513048) also disappears with
a fresh profile.
Whiteboard: [Needs input from beltzner]
Unfortunately I see this today using the beta candidate Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2b1) Gecko/20091019 Firefox/3.6b1, so this will potentially affect beta users.

What is puzzling is that I don't consistently see it on builds - it happens intermittently. I do tend to have three Firefox builds running consistenly on my machine - trunk, Namoroka and Firefox 3.6 beta.
On the lab machine I came back and woke the machine - and this is what the Help menu looked like. What is odd is usually all items are greyed out, but in this instance one on the menu items is active.
Dear lord, don't wait on my QA input to move forward on this bug. Please co-ordinate with Marcia for testing support.
Whiteboard: [Needs input from beltzner]
(In reply to comment #25)

Problem is, you appear to be the only one who is (or was) able to
reliably reproduce this bug who's also willing to do some testing.

So this bug really does depend on you.

Please pick up with comment #22 :-)

To help things out I'll build a new set of tryserver builds (which
should be available in a few hours).  These won't have debug symbols
stripped, since I've now discovered how to make the tryservers not
strip symbols.
It doesn't look like beltzner is going to oblige us with any tests.

So Marcia, could you try the following?

Run one of my tryserver builds from comment #27 for a week (on
machines and in circumstances where you've seen this bug before), and
let us know if you see this bug even once.
Steven, I have good news. Today I had to do a reinstall and 10.6 is now my primary OS. Even without putting my computer into sleep I have disabled menu items in the help menu. I will try your builds later and check if they work for me.
Excellent!  Thanks, Henrik.

I assume your "reinstall" was a non-clean install of OS X 10.6 over OS
X 10.5.8.  If so, was your 10.5.8 install relatively plain-vanilla, or
did it have "interesting" things on it?  And if so, what were the
"interesting" things?
I have directly installed 10.6 and didn't run an upgrade from 10.5.x. So no left-overs which could interfere here.
I haven't tested the tryserver builds yet but I have discovered the following: The items in the help menu are greyed out only for the current window. When I open a new one all the entries are enabled. Switching back to the former window disables them again.
Ok, so I have run those tests on my MBP. Because I wasn't able to reproduce this issue with Minefield I have only checked Namoroka and Shiretoko. Both builds are recent versions and always show the disabled menu items under Help after waking up from sleep. Using the tryserver builds doesn't change anything for me. Shiretoko and Namoroka still have disabled items in the help menu.

This are the steps I did:
1. Start the build with a profile were I'm able to reproduce it 100%
2. Select Apple | Sleep
3. Wait 30 seconds or 1 minute
4. Press space bar to wake up the machine

After step 4 for both builds the entries are disabled.
I know Henrik was not able to reproduce on the trunk, but I have now seen this bug manifest itself on many flavors of Firefox - trunk, 1.9.2 and the Firefox beta candidate.
Marcia:  What machines do you see this on?  Are they all MacBookPros?
I have seen it on the iMac in the lab, so not just on MacBook pros. I believe I have also seen it on my Macbook which I always sleep.

(In reply to comment #35)
> Marcia:  What machines do you see this on?  Are they all MacBookPros?
Using the iMac in the lab, I was not able to reproduce this using the steps in Comment 33 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2b2pre) Gecko/20091102 Namoroka/3.6b2pre.
I got this issue isolated. The root cause are two files under Library/Preferences which are com.apple.screensaver.plist and com.apple.systempreferences.plist. I have send both files to Steven in the hope he can reproduce the problem now on his own. *finger crossing*
Steven, please scratch those two files. They are not necessary. The fact that you don't see that problem is that you don't have enabled the require password checkbox under the Security pane. It doesn't matter which timeout value is given. All values will cause the greyed out help menu.
Summary: [10.6] Firefox Help menu greyed out after waking machine from sleep → [10.6] Firefox Help menu greyed out after waking machine from sleep and 'Require password' enabled
I still can't reproduce this bug, even with "require password"
checked.  There must be one or more additional factors we haven't yet
identified.

I tested with today's and yesterday's Minefield, Namoroka and
Shiretoko nightlies on a fully updated (but otherwise very
plain-vanilla) installation of OS X 10.6.1.  Here's what I did:

1) Start Minefield/Namoroka/Shiretoko and leave it in the foreground.

2) Choose Apple : Sleep.

3) Wait 30-60 seconds.

4) Press the space key to wake from sleep.

5) Enter my password.

6) Use the mouse to open the browser's Help menu.

   Never once did I see any of the items disabled (greyed out).

I get the feeling Henrik's close to figuring out how to reproduce
this.  Please keep trying, Henrik!

But I'm going to try another tack:

Notice that, when you make the current tab blank and open the Help
menu, "Report Broken Web Site..." and "Report Web Forgery..." are both
disabled.  This isn't right (it's a bug).  It happens back to FF 3.0.X
(though interestingly not in FF 2.0.0.20).

A fix for this problem might also fix this bug's problem.
> (though interestingly not in FF 2.0.0.20)

Oops, I was wrong -- it *does* happen in FF 2.0.0.20.

And I forgot to mention that it happens on both OS X 10.5.8 and
10.6.1.
(In reply to comment #40)
> I still can't reproduce this bug, even with "require password"
> checked.  There must be one or more additional factors we haven't yet
> identified.
> 
> I tested with today's and yesterday's Minefield, Namoroka and
> Shiretoko nightlies on a fully updated (but otherwise very
> plain-vanilla) installation of OS X 10.6.1.  Here's what I did:
> 
> 1) Start Minefield/Namoroka/Shiretoko and leave it in the foreground.
> 
> 2) Choose Apple : Sleep.
> 
> 3) Wait 30-60 seconds.
> 
> 4) Press the space key to wake from sleep.
> 
> 5) Enter my password.
> 
> 6) Use the mouse to open the browser's Help menu.
> 
>    Never once did I see any of the items disabled (greyed out).
> 
> I get the feeling Henrik's close to figuring out how to reproduce
> this.  Please keep trying, Henrik!
> 
> But I'm going to try another tack:
> 
> Notice that, when you make the current tab blank and open the Help
> menu, "Report Broken Web Site..." and "Report Web Forgery..." are both
> disabled.  This isn't right (it's a bug).  It happens back to FF 3.0.X
> (though interestingly not in FF 2.0.0.20).
> 
> A fix for this problem might also fix this bug's problem.

Steven, did you make sure to have a couple of tabs open suing your testing?

When I encountered this bug I had around 5-8 tabs own with an assortment of sites.
> Steven, did you make sure to have a couple of tabs open suing your
> testing?

One or two.  Never more.

> When I encountered this bug I had around 5-8 tabs own with an
> assortment of sites.

I'll try this.

Are there certain sites that, if they're present in the active/visible
tab (or perhaps even in one of the invisible tabs), always trigger
this bug?
I wouldn't hesitate to have a flash application running. Other than that any other content sounds good.
> a flash application

If you have publicly accessible example URLs, please specify them.
FINALLY!!

I can now reliably reproduce this bug.

The additional factor is this -- at least one plugin must be loaded.

Any plugin will do.  The number of tabs doesn't matter.  The problem
happens even if the plugin is in an invisible tab.  The problem
happens even if the plugin is invisible in the current tab.

I tested with my DebugEventsPlugin from bug 441880 and the following
two URLs (each of which loads exactly one, visible plugin):

http://www.rogerdean.com/
  (loads one Flash plugin)
http://java.sun.com/applets/jdk/1.4/demo/applets/Clock/example1.html
  (loads one Java applet)

I also tested with the page you get after logging in at
https://mail.google.com/ (which contains several invisible Flash
plugins).

So here are STR for this bug (on OS X 10.6.X):

1) In the Security pref panel, select "require password after sleep or
   screen saver begins".  The interval doesn't matter, but you must be
   prompted for your password (after waking from sleep) to see the
   bug.

2) Start Minefield/Namoroka/Shiretoko and load at least one plugin.
   You can do this by visiting the following site (which loads one
   Flash "movie"):

   http://www.rogerdean.com/

   Leave the browser in the foreground.

3) Choose Apple : Sleep, then wait about 30 seconds.

4) Press the space key to wake from sleep.

5) Use the mouse to open the browser's Help menu.

   When you do this, all the items in the menu will be disabled
   (greyed out).
The problem also happens in FF 3.0.15.

It doesn't happen in Safari or FF 2.0.0.20.
Problem doesn't happen on OS X 10.5.8.

I needed to check :-)
Summary: [10.6] Firefox Help menu greyed out after waking machine from sleep and 'Require password' enabled → [10.6] Firefox Help menu greyed out after waking machine from sleep and 'Require password' enabled, if plugin loaded
Summary: [10.6] Firefox Help menu greyed out after waking machine from sleep and 'Require password' enabled, if plugin loaded → [10.6] Firefox Help menu greyed out after waking from sleep if plugin loaded and "Require password" enabled
This is a really wacky bug, and weird condition to cause it. Steven do you have a rough idea of a fix?
The bug happens if a plugin was ever loaded in the key window (for
example if you loaded it and then visited a page without any plugins).

It doesn't happen if no plugin was ever loaded in the key window --
even if a plugin is loaded and visible in another browser window
that's not key at step 3.

> do you have a rough idea of a fix?

No idea at all.  But the crucial thing is it's now reproducible.  A fix/workaround shouldn't be too hard to find.  (I say workaround because this is likely to be an Apple bug.)
(In reply to comment #46)
> FINALLY!!

That sounds fantastic Steven! I thought I would have to do once more a session.
 
> The additional factor is this -- at least one plugin must be loaded.

Mmh, has one of the two start pages (when you first launch a profile in Firefox) some plugin content? Then it could be the reason. If not then this step is not necessary for me.
(In reply to comment #51)

> has one of the two start pages (when you first launch a profile in
> Firefox) some plugin content?

No.  So I suppose there's yet another factor :-)
(In reply to comment #46)
> 3) Choose Apple : Sleep, then wait about 30 seconds.
> 4) Press the space key to wake from sleep.

I would add that the sleeping is not required here, just locking and getting prompted for a password (eg by setting a corner of the screen to start the screen saver with Expose). My machine never sleeps but I unlock it several times a day from the screensaver. 10.6 w/ Namoroka nightly, with Gmail using the flash plugin.
Component: Menus → Widget: Cocoa
Flags: blocking-firefox3.6+
Product: Firefox → Core
QA Contact: menus → cocoa
Version: 3.6 Branch → 1.9.2 Branch
This lost its flag in component move - still blocks.
Flags: blocking1.9.2+
(Following up comment #46)

My STR is slightly wrong -- it doesn't work in recent trunk/Minefield
nightlies.

This is true as of the firefox-2009-09-16-03-mozilla-central nightly,
and more specifically as of the following patch:

changeset:   32502:594dd7f280fa
user:        Josh Aas <joshmoz@gmail.com>
date:        Tue Sep 15 13:02:12 2009 -0400
summary:     Use gcc-4.2 and the 10.5 SDK by default in Gecko 1.9.3.
             Gecko 1.9.3 builds will no longer run on Mac OS X 10.4.
             b=501436 r=ted

If anything, this only makes the mystery deeper -- I can't see how
this patch could have "fixed" this bug.

I'll keep digging.
This bug keeps getting stranger.

I've discovered my STR from comment #46 is seriously wrong.  Here's a
revision:

1) In the Security pref panel, select "require password after sleep or
   screen saver begins".  The interval doesn't matter, but you must be
   prompted for your password (after waking from sleep) to see the
   bug.

2) Start Namoroka/Shiretoko/GranParadiso and press one key, once.

3) Choose Apple : Sleep, then wait about 5 seconds.

4) Press the space key to wake from sleep.

   Enter your password when you're prompted to do so.

5) Use the mouse to open the browser's Help menu.

   When you do this, all the items in the menu will be disabled
   (greyed out).

Believe it or not!! :-)

But I've also made substantial progress -- I've discovered the bug is
due to a mismatch between the Cocoa and Carbon enabled states of the
items in the Help menu.  So, one way or another, I should have a patch
for this bug tomorrow.
Here's a workaround for this bug.

It's surely an Apple bug.  But I haven't been able to find out exactly
what the bug is, or what triggers it.  The only thing that's clear is
what I mentioned above -- the symptoms are caused by a mismatch
between the Cocoa and Carbon enabled states of the items in the Help
menu.  My patch narrowly addresses these symptoms.

I figure something is disabling the Help menu's Carbon menu items
without regard for the enabled state of the corresponding Cocoa menu
items.  The Carbon call to disable a menu item is DisableMenuItem().
But when I make this a breakpoint in gdb, I don't see it happening.

Since the bug cooincides with a password dialog that probably runs in
another process, I suspect the Carbon menu items are being disabled
from that process -- which wouldn't be traceable when running Firefox
in gdb.

Here's a tryserver build made with this patch:
https://build.mozilla.org/tryserver-builds/smichaud@pobox.com-bugzilla513048-192branch/bugzilla513048-192branch-macosx.dmg

Since this bug is (apparently) no longer reproducible on the trunk,
the patch and the tryserver build are on the 1.9.2 branch.

Please try out the tryserver build!  Particularly you, Henrik! :-)

If you get good results, I'll ask for review.
Steven: Going to grab your tryserver build now and will report back. It is interesting that the Security Panel pref plays into it.
(In reply to comment #57)
> Since the bug cooincides with a password dialog that probably runs in
> another process, I suspect the Carbon menu items are being disabled
> from that process -- which wouldn't be traceable when running Firefox
> in gdb.

Those password dialogs are modal. Without your patch the menu items aren't getting disabled when you start/stop the screensaver or go to sleep and wake it up again. While a modal dialog is open all of the menu items except the application menu are hidden. 

> Please try out the tryserver build!  Particularly you, Henrik! :-)

Works like a charm Steven! Menus don't get greyed out anymore.

> If you get good results, I'll ask for review.

Woot!
Status: NEW → ASSIGNED
Your tryserver build works for me as well. I ran it, and then when I went back to the latest nightly I immediately saw the bug.
Attachment #410872 - Flags: review?(joshmoz)
Comment on attachment 410872 [details] [diff] [review]
1.9.2 branch patch/workaround

Wonderful!  I'll ask for review right now.
Comment on attachment 410872 [details] [diff] [review]
1.9.2 branch patch/workaround

Oops, I forgot to put "::" in front of the Carbon methods I call.

I'll do that on landing.
Steven, can you do a quick spot-check test on your tryserver build with loaded
plugin applications in open tabs too - just so we can negate comment #50?
I tested the tryserver with no plugins loaded and with plugins loaded, and there was no difference for me.

(In reply to comment #63)
> Steven, can you do a quick spot-check test on your tryserver build with loaded
> plugin applications in open tabs too - just so we can negate comment #50?
(Following up comment #55)

Here's why this patch fixes the problem on the trunk ... probably.

The patch makes trunk builds use the 10.5 SDK (instead of the 10.4 SDK
that's used on older branches).  This means that the trunk no longer
depends on Carbon events (kEventMenuOpening, kEventMenuClosed and
kEventMenuTargetItem) to find out that a menu has opened or closed, or
to track mouse movement over a menu.  I'll bet the bug goes away when
we use menu:willHighlightItem:, menuWillOpen: and menuDidClose:
instead.
Comment on attachment 410872 [details] [diff] [review]
1.9.2 branch patch/workaround

This workaround is fine, we should probably take it on trunk too but ifdef'd like the other 10.4 code still there.
Attachment #410872 - Flags: review?(joshmoz) → review+
Summary: [10.6] Firefox Help menu greyed out after waking from sleep if plugin loaded and "Require password" enabled → [10.6] Firefox Help menu greyed out after waking from sleep if key pressed and "Require password" enabled
Landed on the 1.9.2 branch:
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/0e5b959c2153

> we should probably take it on trunk too but ifdef'd like the other
> 10.4 code still there

I'll do that in a bit.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
status1.9.2: --- → final-fixed
Resolution: --- → FIXED
Steven, I think we should use that bug for trunk too. So lets reopen until it's fixed there too.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Actually this bug doesn't exist on current trunk, as best I can tell (see comment #65).  So it doesn't need to be "fixed" there.

What Josh suggested (and I agreed to) is just housekeeping -- it won't get compiled on trunk (as it's now configured).
Housekeeping patch landed on trunk:
http://hg.mozilla.org/mozilla-central/rev/d152de3b7328
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
This morning when I woke my computer up from sleep, I wanted to get the nightly update but the help menu was greyed out on Namoroka 20091122.  After updating I was able to reproduce using the STR in comment #56 on 10.6.2:
  Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2b4pre) Gecko/20091123 Namoroka/3.6b4pre

Also reproducible on a new profile (including in safe-mode) on the day after the landing of the patch:
  Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2b3pre) Gecko/20091111 Namoroka/3.6b3pre
and the day after that:
  Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2b3pre) Gecko/20091112 Namoroka/3.6b3pre

Note that this also seems to affect 1.9.1 (based on reports[1] on SUMO).  It probably should be fixed there before we start telling people to check for updates when 3.6 is released.

[1] http://support.mozilla.com/nl/forum/1/493467 & 
    http://support.mozilla.com/kn/forum/1/492714
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2b4pre) Gecko/20091122 Namoroka/3.6b4pre

I also saw a grayed out Help menu when I came back to my machine this morning, but I can't reproduce it by engaging the screensaver and then unlocking.

Should the status1.9. flag be reset ?
The current problem is much less severe than the original problem --
it only happens the first time you open the Help menu over a given
browser window.

This probably shouldn't have been reopened.  In fact I'm going to
close it again.

I haven't had a chance to look into this very far ... but I think I
know what's going on (and how to fix it).
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
I'm going to open a new bug on the new problem.
It's bug 530633.
Depends on: 530633
Given by bug 530673 we have the same problem on 1.9.1. Setting status flag.
status1.9.1: --- → ?
I confirm, same issue with 1.9.1. as well
Attached image Issue with 1.9.1. — 

    
    

    
  
Stefano, we don't need any more confirmations here. Before we can try to get it on 1.9.1 bug 530633 has to be fixed first.

    
    

    
  
I am confused. If the bug is confirmed in the branch, why is it resolved as fixed?

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: