182642 - 'available profiles' label can be 'deleted' by user

Status: RESOLVED FIXED

(SeaMonkey :: Startup & Profiles, defect)

Description

[Mike Coppins]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016

On Mozilla 1.2 and 1.2b, if I delete all available profiles, then click the
delete button again, the 'available profiles' label above the list box disappears.

Reproducible: Always

Steps to Reproduce:
1.  start profile manager.
2.  delete all profiles (removing files for that profile or not)
3.  click the delete button again.

Actual Results:  
the 'available profiles' label disappears.

Expected Results:  
It shouldn't have removed a part of the interface, when clicking the delete button.

Comment 1

[Grace Bush]

confirming with mozilla 1.2b and 1202 trunk build

Comment 2

[Mike Coppins]

confirming with 1.3 release.

Comment 3

[Kevin Brosnan]

Well this is still present in 1.7b.

Comment 4

[Stefan Borggraefe]

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

Comment 5

[Stefan Borggraefe]

Also happens on Linux with a 1.8a build from yesterday.

The following JavaScript exception is thrown when the Listbox header disappears: 

JavaScript error: , line 0: uncaught exception: [Exception... "Component
returned failure code: 0x80004005 (NS_ERROR_FAILURE)
[nsIListBoxObject.getIndexOfItem]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)" 
location: "JS frame :: chrome://global/content/bindings/listbox.xml ::
ensureElementIsVisible :: line 476"  data: no]

Comment 6

[Stefan Borggraefe]

Attachment: Fixes the bug

This happens because DeleteProfile uses
  selected.previousSibling;
instead of
  profileList.getPreviousItem(selected, 1);
to get the listitem to select after the profile deletion.

selected.previousSibling returns the listbox header when the last profile is
deleted, while getProviousItem() return null when there are no more listitems.

The patch also moves the selection of the previous listitem inside the
try-block so this only happens when the profile deletion was actually
successful.

Comment 7

[jag (Peter Annema)]

Comment on attachment 147116 [details] [diff] [review]
Fixes the bug

The fix itself looks good.

Someone might object to the change in white space style though. Seeing how this
file is a rather ugly mix of two styles, I'm more than happy to say yes to
these whitespace changes, though the majority style seems to be the one you're
actually moving away from. Hmmm... Who owns this stuff anyway? I'd say run it
by them, but you have my blessing. r=jag

Comment 8

[Stefan Borggraefe]

Conrad: Seems like you are the only Profile Manager peer currently available.
Are you ok with my whitespace changes or should I revert them? I could also fix
the whole file to use one style before checkin.

Comment 9

[Stefan Borggraefe]

Comment on attachment 147116 [details] [diff] [review]
Fixes the bug

Lets ask a super-reviewer before I forget about this patch. ;-)

Alec: Are you ok with the whitespace usage in my patch? Should I perhaps change
the whitespace usage in the whole file to be consistent before checkin?

Comment 10

[Alec Flett]

Comment on attachment 147116 [details] [diff] [review]
Fixes the bug

sr=alecf

Comment 11

[Stefan Borggraefe]

fixed