Closed Bug 70097 Opened 24 years ago Closed 23 years ago

pressing up/down in folder pane focuses thread pane

Categories

(SeaMonkey :: MailNews: Message Display, defect, P1)

Product:
SeaMonkey
Component:
MailNews: Message Display
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.8

People

(Reporter: jruderman, Assigned: ssu0262)

References

Details

(Keywords: access)

Attachments

(1 file, 3 obsolete files)

patch v1.3
3.10 KB, patch
racham
: review+
sspitzer
: superreview+
Details | Diff | Splinter Review 
Steps to reproduce:
1. Click on "inbox".
2. Press down.

Result: thread pane now has focus.
Expected result: message pane retains focus until I press tab.

In bug 65667 there was some discussion about making it so that when you click 
on a folder, the thread pane becomes selected.  I don't like that idea, because 
it means you would be clicking on one thing to focus another thing, and because 
it would make it awkward to actually get focus in the folder pane.
Cc mpt and aaron.
Keywords: access
Yes, we just noticed this the other days as well.
There are a number of issues with this.
There will probably be some keys that are used for "next folder" and "next
unread folder" etc.
In addition, some people have suggested that trees act as a list do - that is,
you can type alphanumeric keystrokes and it moves the selection bar to the first
tree item that starts with that combination of characters. Typing the same
letter a number of times moves to the nth folder that starts with that letter.
This is how it works in Windows, try it in Outlook Express.
->all since we've seen this on linux... but, to be sure: nbaca, have you seen
this on mac? thx!
OS: Windows 98 → All
QA Contact: esther → nbaca
Hardware: PC → All
I think this will be XP.  alecf added some code to switch focus to the thread
pane after a folder loads.

it's a nice feature for when the inbox gets selected automatically for you at
startup.

we'll have to think this one through. 
How about just selecting the inbox and focusing the thread pane at startup?  
Then, after that, if the user clicks in the folder pane, leave the thread pane 
focused until the user clicks on the thread pane, presses tab or ctrl+tab, or 
uses one of the single-letter "next/prev message" keys.
actually, I was thinking of how extending the thread-pane thing to the message pane.
how about when a message finishes loading, the focus goes to the message pane.
then space would auto-scroll the message too.
That would solve the spacebar issue, but then you would have to tab back to the
thread pane if you wanted to arrow up/down.  (Not sure if that would bother
people or not -- maybe people would like it better that arrows now scrolled the
message.)

Couldn't spacebar in the thread pane just be bound to "scroll the message in the
message pane"?  Seems like that would be an easier way of fixing the spacebar
bug without having to shift focus (and then you wouldn't have to worry about
spacebar maybe not scrolling after you clicked on the same header again).
I'm not sure about the default startup behavior but I basically like the 4.x
implementation after messages have been selected in various folders. This is
what I observed when using 4.x and an IMAP account:

- At startup the Inbox is surrounded by a dotted line, with messages appearing
in the thread pane and the Start Page displaying in the message pane.
- If the Inbox folder is selected then it remains highlighted
- If a message in the thread pane is selected then the header of the message
remains highlighted and the contents of message is in the message pane
- Switch to a second folder and only the folder is selected
- Select a message in the thread pane and the header in the thread pane is
selected while displaying its contents in the message pane
- Switch to the Inbox folder and the Inbox folder is selected but the message in
the thread pane is surrounded by a dotted line and the contents of the message
are displayed in the message pane.
Making space scroll the message while the thread pane is focused is bug 33507.

I don't think it would be a good idea to focus the message pane after clicking 
on a message -- that kind of thing often causes to the type of problem that led 
to this bug report.
I agree with nbaca, i like the 4.x implementation.
So the only open issue is whether we move focus from the thread pane to the 
message pane when a message is displayed? For key stroke users, the behavior 
then becomes:
1. Select Message in thread pane
2. Read message
3. Hit tab twice or shift+tab to move back to thread pane
4. Key Scroll

Is this the behavior we want, or do we assume that folks want focus to remain in 
the thread pane?
Keep focus in the Thread pane unless user tabs/selects the message pane.
I agree.
wait, in 4.x, alt-up/alt-down moved around in the thread pane, and the arrow
keys moved the message pane...
In 4.x windows the up and down arrow keys move up and down in the pane that 
currently has focus.  For example, if the Thread pane has focus, the up/down 
arrows move up/down from message header to message header. If the Folder pane 
has focus, the up/down arrows move selected from folder to folder.

Alt up/down seems to jump to the next *unread* message header, when the Thread 
pane has focus, the message pane has focus or the folder pane has focus.
In the absence of either bug 54171 or a useful Account Central page, there are 
only two ways to tell how many messages are present in each of your folders. The 
first, tiresome, way is to scrub the folder pane with the mouse, and wait for the 
tooltips to appear over each folder name. The second, easier, way is to focus the 
folder pane, then select each folder one by one (e.g. by using the arrow keys) 
and inspect its contents in the thread pane and status bar. For Mozilla to 
constantly push the user into the thread pane when they are trying to do this, 
making them press Shift+Tab (or Tab twice) to get back to the folder pane every 
time, is rather obnoxious.

I can only think of one situation in the entire Mozilla suite where Mozilla 
should move focus from one visible element to another visible element, in the 
same window, without the consent of the user -- and this isn't it.

Aaron's and Jennifer's comments are rather orthogonal to this bug. This is a 
focus issue, not a keyboard shortcut issue.

what mpt said.  I switch between 4.x at home and 6.x at work (both win98se) and
for some reason the folder counts don't get updated correctly when I switch back
and forth.  So I end up having to click in the folder pane, then use the arrow
keys to go down over each folder to have it update the message count so I know
what folders have unread messages in them.  In 4.x this is easy, just click
once, then down arrow over every folder.  In 6.x this is a pain since I have to
click on each folder because the focus goes back to the thread pane after every
click.  Very annoying, especially due to the speed of 6.x.

Isn't this a 4x feature parity issue?
Keywords: 4xp
this is intended behavior - because 99% of the time, when a folder is loaded,
you want the arrow keys to navigate the thread pane...
For mouse users it does make sense to say the majority of the time that the user
will want the focus to be in the thread pane. 

For keyboard users I would prefer that the focus remain on the folder so the
down/up arrow can move between folders and then let the user tab to the next
pane if desired.
Mouse users usually don't care where focus is.  Keyboard users often do, and
they'll be annoyed if they can't figure out how to focus the folder pane with
the mouse *and* with the keyboard.
*** Bug 78818 has been marked as a duplicate of this bug. ***
Marking nsbeta1 because I think it is important to fix, although I realize bug# 
70097 is a dupe of this bug and was marked for 0.9.3.
Keywords: nsbeta1
Copying nsbeta1+, P3, and 0.9.3 milestone from dup.
Keywords: nsbeta1 → nsbeta1+
Priority: -- → P3
Target Milestone: --- → mozilla0.9.3
Putterman uses status whiteboard for nsbeta1+ tracking... fixing for him. :)
Keywords: nsbeta1+
Whiteboard: [nsbeta1+]
Keywords: nsBranch
to satisfy both situations, perhaps we could do this:

if the folder pane has focus, and the user hits "down", we'll only transfer
focus to the thread pane after a certain number of micro seconds.

that way, if the user hits down down down, we'll do the right thing.

comments?
I think it would be great if we could avoid changing focus for someone just
arrowing down.  I don't know what the time is, but perhaps 1/2 a second before
focus changes?
sspitzer's suggestion sounds good to me, but I would make it a large # of
microseconds (on the order of 1000 ;-) because the only time I ever arrow down
through the folders is to have mail open the folder and update the mesg count
for the folder to check if there are any new messages in that folder.  So the
delay would have to be something like a second after the folder message count is
updated.
I don't like the delay idea.  The delay would have to be considerably longer
than a second to allow me to see whether there's anything worth reading in the
folder, but then the feature becomes less useful for mouse users because they
have to wait before they can use arrow keys to scroll through the thread pane. 
Also, many users will wonder why focus moved to the thread pane (or why the
black ring moved, if they're not familiar with the idea of focus) even though
they haven't touched anything for over a second.
another idea, this might have already been suggested (and I'm not sure it is
possible but...)

if the user uses the mouse to select a folder (or if we automatically select the
folder, for example the inbox on startup), we switch focus to the thread pane.

if the user is using keys, we don't switch focus.  (I figure if they are using
keys, they don't want focus to jump on them.)

comments?
I support the last suggestion. Sounds more reasonable.
or how about abstracting it out to any keyboard input - I'm imagining something
where in onkeydown, you record some bit like "keyboard in use" state - then the
folder changes, then you have an onkeyup event - the onselect event should
happen in between
If we can detect key state vs. mouse click, then that sounds reasonable. I don't
like the idea of a *delay* trying to presume what threshold is comfortable. The
only expected behavior we can predict is keys vs. mouse - not the variables
around perceived delay, speed of machine, etc.
I wouldn't care about this bug if I could trust seamonkey to accurately reflect
the read/unread message status for each folder.  When I switch between 4.x and 
6.x I almost always find one or two folders that have unread messages but are
not bold, which is why I end up going through all my incoming folders.
If Mozilla changes focus without the user's permission, it will look buggy. If 
Mozilla changes focus without the user's permission, after a delay, it will 
look slow *and* buggy. (It already has a delay, of about ten seconds!) If 
Mozilla changes focus or not depending on the input device, it will look 
inconsistent *and* slow and buggy.

You're trying to be too clever here.
right now, clicking on another folder doesn't change the focus but using the up 
and down does.  I'll work on fixing that first.

clicking on "Read Messages" in account central loads the inbox and sets focus 
to the thread pane, I believe that is correct.

on start up, if we are set to "check for new mail on startup", we select the 
inbox for the default account automatically and we set focus to the thread 
pane.  I believe that is also the correct behavior.
it's actually the folderloaded event that focuses the thread pane.....on my
build, when I click on a folder, there is a brief pause while the folder loads,
then the focus arrives in the threadpane. I thought that we actually had a
similar trick in the thread pane such that you could hit up/down in the thread
pane to move between messages, and it wouldn't load the message until after a
slight delay?

by the way, I completely disagree with mpt that if we change the focus without
the users permission, that it will look buggy. Matthew, I suggest you TRY to use
the product with the thread pane not focusing automatically, and using the "N"
key to go to the next message, I think you'll see how frustrating it can be.
>it's actually the folderloaded event that focuses the thread pane.....on my 
>build, when I click on a folder, there is a brief pause while the folder loads,
>then the focus arrives in the threadpane. 

ah, that's what it does for me with IMAP, but not pop (local folders.)

we must not be sending the folderloaded event for local folders.

>I thought that we actually had a
>similar trick in the thread pane such that you could hit up/down in the thread
>pane to move between messages, and it wouldn't load the message until after a
>slight delay?

we do, some sort of timed select.

>by the way, I completely disagree with mpt that if we change the focus without
>the users permission, that it will look buggy. Matthew, I suggest you TRY to 
>use the product with the thread pane not focusing automatically, and using 
>the "N" key to go to the next message, I think you'll see how frustrating it 
>can be.

if for 4.x if the folder pane had focus, "n" would switch to the thread pane go 
to the next unread message.  the same should be possible in 6.x.
Ok, i just recently tried to use AIM's preference dialog. It's unusable because 
pressing the arrows results in focus switching to some stupid panel.

otoh, icq's preference dialog, which will not win awards, doesn't do this, and 
is much better than aim's for this reason alone.
nbaca already mentioned what 4.x did.  I tried Outlook Express and it also keeps
focus on the folder pane.  I thinke we should do the same.  In current builds if
you hit 'n' for next unread or 'f' for next message it moves the selection in
the thread pane which is what we want.  It doesn't currently cause focus to
change.  I'd rather have that cause the focus change than loading a folder.  I
think it's fine if the Inbox starts up with focus in the thread pane like 4.x
but any folder that the user changes by mouse or keyboard should keep focus in
the folder pane, in my opinion.  I also think it's better to keep focus in the
thread pane if the folder gets loaded due to Next Unread Message and Advance to
next folder. But if the user selects the folder, I think it should keep focus. 
Right now it's very awkward to perform and folder operation.

Alec, it looks like 'n' and 'f' work.  What were your other concerns besides that?
I agree. Still allowing 'n' and 'f' operations although focus is in the Folder
Pane seems right. However, scrolling using the arrow keys while in the folder
pane: focus should remain since the user has clicked there (moved focus), but
Next Unread and Next Message then are considered "thread pane operations" and
moves focus to the thread pane. Is that not what we're driving at?  
I think it makes sense for N/F to switch focus from the folder pane to the
thread pane, but some of our users depend on it not switching focus from the
*message* pane to the thread pane.  Is it possible to make N/F switch focus to
the thread pane only if the folder pane was focused before?
I agree with putterman's comments on 2001-07-02 22:25.
ok, when I get back to this I'll do what putterman suggested.

besides n and f, we need to worry about space and any other key board command
under the "Go" menu (next flagged, etc.)
Status: NEW → ASSIGNED
Keywords: nsBranch
Priority: P3 → P2
not going to happen on the nsBranch, but on my list for 0.9.3
under the Go menu there is:

f for Next > Message
n for Next > Unread Message
t for Next > Unread Thread
b for Previous > Message
p for Previous > Unread Message

do we care about m for Mark > Read/Unread under the Message menu? ie, any other
single-key shortcut in other mailnews menus (if i'm missing others)? just
curious...
Yes, all those keyboard shortcuts, and all shortcuts except those which for
which focus changes their meaning (arrow keys, Page Up/Down, Delete), should do
the same thing no matter what pane has focus.
*** Bug 92108 has been marked as a duplicate of this bug. ***
moving to 0.9.4
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Blocks: 92693
slide to 0.9.5
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Keywords: nsBranch, nsenterprise
I thought the Keywords nsBranch/nsenterprise meant that this bug should be fixed
in 0.9.4. If this is sliding to 0.9.5 then should these keywords be removed or
changed to include a minus?

p.s. I would still like to see this fixed for this release, if possible.
Removing nsenterprise nomination.
Keywords: nsBranch, nsenterprise → nsbranch
Blocks: 99230
not a stopper for eMojo. triaging for the next release.
Keywords: nsbranch → nsbranch-
Target Milestone: mozilla0.9.5 → mozilla0.9.6
No longer blocks: 99230
now I'm running into 95527 (message counts inaccurate), and have to click on
every single folder I filter mail into every morning.  It would make that bug
much easier to take if I could click once in the folder pane and then down-arrow
through each folder.
reassigning to ssu.
Assignee: sspitzer → ssu
Status: ASSIGNED → NEW
Keywords: nsbeta1
Whiteboard: [nsbeta1+]
marking nsbeta1+
Keywords: nsbeta1 → nsbeta1+
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Blocks: 107067
Keywords: nsbranch-
QA Contact: nbaca → olgam
Priority: P2 → P1
I am glad that I found confirmation to my thoughts in comments #35 (Default
Focus) and #39 (common user behavior).
It looks like the findings shown in 112477 say that this is almost fixed. What's
left is making sure that you can get out of the folder pane by some other means
besides tab, such as 'n' or 'f'.

Scott
re: comment 57: scott, that would be a good idea, using the single-letter shortcuts.

currently, the single-letter shortcuts do display the appropriate message [eg,
'n' displays the first unread message in the selected folder, 'f' the first
read/unread message, etc]. however, focus does remain in the folder pane, rather
than switching to the thread pane. shall i file a separate issue for that?
sairuh, filing that bug would be great.  I'm a little hesitant to mark this bug
fixed until we somebody can say what caused the change in behavior in recent builds.
filed bug 112771.

yeah, the recent change in focus behavior is rather odd. anyone have any ideas
as to why?
this bug is still there in today's build.  However, it only happens when you
arrow down onto a folder that contains no messages.  This happens for me under
Win32.
Status: NEW → ASSIGNED
Attached patch patch 1.0 (obsolete) — — Splinter Review 

    
    

    
  
This patch fixes the original problem of: arrowing up/down switches focus to the
thread pane.

It will no longer do this on any folder (empty or not).

    
    

    
  
Comment on attachment 60271 [details] [diff] [review]
patch 1.0

r=varada

        Attachment #60271 -
        Flags: review+

    
    

    
  
hold up, I don't think this is the right / complete fix.

I need to read back in the bug history and see what jglick and others decided.

    
    

    
  
related to bug 65667/bug 112477: using a build from 12/10 now exhibits behavior
of the thread pane gaining focus after a folder is selected [ie, when i
mouseclick a folder, or arrow/up down to select a folder]. wonder why it
reverted. odd.

    
  
Target Milestone: mozilla0.9.7 → mozilla0.9.8

    
    

    
  
IMO, the patch do the right job.


    
    

    
  
The patch fixes the problem - why isn't it checked in yet?

    
    

    
  
I can't remember now why I wanted you to wait.

Re-reading the bug, it looks like putterman and jglick agreed on this:

1) up / down arrows should not cause us to switch focus to the thread pane.
2) navigation (like 'n') should put the focus back on the thread pane after
loading the next folder.
3) I think (based on http://bugzilla.mozilla.org/show_bug.cgi?id=70097#c39)
putterman and jglick think
that clicking on a folder should not throw the focus to the thread pane.

does #2 still work with your patch?  Can you check the code to make sure we do
that for the other cross
folder navigation commands?

My one concern is that #3 is not correct.  

For example, on start up, when I have my prefs set to
load my inbox, should focus be in the thread pane or the folder pane?  (I bet
it's cause of the existing code that
we go to the thread pane.)

Should we make it so on clicking (and on navigation commands) we want to shift
focus, but on non-click we don't?

When testing any fix, make sure to try news, local (pop) and imap (for clicking
and for the "load my inbox at startup" scenario I described).  I think that one
(IMAP) might generate folder event that cause us to switch focus, where the
others might not.   (I vaguely remember this from some performance testing that
cavin was doing.)

jglick / putterman, can you confirm again what we want?

    
    

    
  
#2 actually is not working on the trunk right now.  And my patch keeps it
working as it is, which is to not put focus back on the threadpane when hitting
either 'n' or 'f'.

I actually agree with #3.  It turns out that this patch makes #3 work that way.

For your 'on startup' comment, I had asked Scott and Jennifer about it at one
point because it was a seperate fix.  Both like it to set the focus on the
thread pane on startup, so I left it as is.

I tried news, local (pop) and imap (for clicking and for the "load my inbox at
startup" scenario you described):  news, local (pop), and imap all no longer set
focus to thread pane when arrowing up/down in folder pane or hitting 'n'/'f'.

Clicking on folders also no longer set the focus on the thread pane (it used
to).  The threadpane focus on start up is not affected by this patch.



    
    

    
  
I still agree with #3.  I think that the first time you start up it makes sense
to put focus on the thread pane because that's not a user initiated action.  But
if the user moves to a folder, whether by keyboard or mouse, I think it should
stay there.  

I do think we need to make "n", "f", and the arrow keys work when a folder is
selected such that they bring focus to the thread pane and perform their
specific action.

    
    

    
  
I agree with putterman, comment #71, #39.


    
    

    
  
I agree with putterman and jglick, comment #39, comment #71.
It seems we are in a good shape. I check focus when navigate by "n", "f" or
arrow keys from Mail default state. It works fine.
If we all agree with discussed logic, I'll go through detail verification with
each type of account.


    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch v1.1 (obsolete)
        — 
          — Splinter Review
      

    


  
This new patch will:
1) leave focus on the folder pane when either clicking or arrowing to folders
in the folder pane.
2) set the focus to the thread pane only if the focus is not on the message
pane when hitting the following keys: 'n', 'f', 't', 'b', 'p', ' '
Meaning that if the focus is on the message pane, hitting the above keys will
not set the focus to the thread pane.

        Attachment #60271 -
        Attachment is obsolete: true

    
    

    
  
Sean, in 2) you say: 'set the focus to the Thread pane only if the focus is not
on the message pane'. I believe, you also meant Not in Quick Search, nor
Advanced button. 
So, expectation  is to have focus in Thread pane with letter navigation in case
of focused by default Inbox or having focus in Thread pane. Currently if focus
is in the Message Body pane, clicking on 'n' moves focus to the next unread
message in Thread pane.

    
    

    
  
I talked to Scott about this and got clearification that if the focus is
currently on the Message Pane, then hitting the keys to navigate messages will
not move the focus elsewhere.

Focus will only be set to the Thread Pane if the focus is currently on any of
the following panes when the navigation keys are used:
  Folder Pane
  Search Pane
  Search Button


    
    

    
  
If focus is on the Search field AND I click 'n' - it means that I do Search on
'n', but not looking for the next unread message. Focus should stay in Search.

    
    

    
  
You are absolutely correct.  If the Search field has focus, and the nav keys are
used, it will not move the focus away from this field.  However, if the Advanced
Search button has focus, then the focus will be changed to the Thread Pane.

    
    

    
  
If focus is on a button and a key is pressed the key should go to the button, 
or any related buttons. it should *not* go to some random field that's an 
uncle of the button.

    
    

    
  
Right now, the patch does not break the functionality of how the button gets
triggered via the keyboard.  There isn't a way to set an access key to the
button and have it trigger the button.  

    
    

    
  
ssu, with your last patch does ' ' still do the right thing in the message pane?

if the message pane or thread pane has focus, space will do a page down in the
message pane (for long messages), and once at the bottom, space will act like
you hit 'n'.

    
    

    
  
yes.  the ' ' key still works as expected with the patch.

    
    

    
  
instead of adding a call to SetFocusThreadPaneIfNotOnMessagePane() after
(almost) every call  to GoNextMessage(), why not add the call to
SetFocusThreadPaneIfNotOnMessagePane() to the end of GoNextMessage()?

note, you missed one call to GoNextMessage()

      case "cmd_killThread":
        /* kill thread kills the thread and then does a next unread */
      	GoNextMessage(nsMsgNavigationType.toggleThreadKilled, true);
        break;

also, double check the white space on your final patch.


    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch v1.2 (obsolete)
        — 
          — Splinter Review
      

    


  

        Attachment #65137 -
        Attachment is obsolete: true

    
    

    
  
I'd suggest writing SetFocusThreadPaneIfNotOnMessagePane() in a way where you 
only call both GetXXX() if you have to.

If you have a guess what has focus more of the time (thread pane or message 
pane), you could order them in a way to avoid the second GetXXX() call.

for example, if you knew that the thread pane has focus more often that the 
message pane, you could do this:

function SetFocusThreadPaneIfNotOnMessagePane()
{
  var focusedElement = WhichPaneHasFocus();

  if((focusedElement != GetThreadOutliner()) &&
     (focusedElement != GetMessagePane()))
    SetFocusThreadPane();
}



    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch v1.3
        — 
          — Splinter Review
      

    


  

    
    

    
  
Comment on attachment 65325 [details] [diff] [review]
patch v1.3

sr=sspitzer

jglick, can you amend the spec to cover this behaviour?

        Attachment #65325 -
        Flags: superreview+

    
  
Blocks: 112771

    
  

        Attachment #65325 -
        Flags: review+

    
    

    
  
r=bhuvan

    
    

    
  
a=blizzard on behalf of drivers for 0.9.8
Keywords: mozilla0.9.8+

    
    

    
  
patch checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED

    
    

    
  
*** Bug 120801 has been marked as a duplicate of this bug. ***

    
    

    
  
I think the focus should remain in the Folders pane in any case, this is the
expected result in Windows and I find incongruent to move focus . it has a
reason, too. just consider when consulting folders (i.e. to check titles): you
must do it very fast to avoid the focus loosing action! 

    
    

    
  
Verified on Linux, Win2K - with IMAP, POP, News - 01-29-2002 build.
Partially on Mac OSX - can not get focus on Advanced button - the button skipped
when navigate by Tab, or F6.

Focus is set to the Thread Pane when the navigation keys are used - if the focus
is currently on any of the following areas:
    Folder Pane - up/down arrows or letter navigation (both from default state
and a Folder is intentially selected). Also letter navigation - when a Folder is
intentially selected.
    Search Button - by using letter navigation: f, n, t, b, t, p.

From Search field: Navigation arrows or letters do not move focus to Thread pane. 

Also I verified that if the focus is currently on the Message Pane, we can
navigate messages by letters (f, n,) but focus do not move elsewhere.

Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: