Closed Bug 367157 Opened 13 years ago Closed 13 years ago
Cannot uncheck migrators on data migration wizard
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:18.104.22.168) Gecko/20061204 Firefox/22.214.171.124 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a2pre) Gecko/20070116 Calendar/0.6a1 When you start up either Sunbird or Lightning on a new profile, the data migration wizard appears. It will list sources of data to migrate into Sunbird/Lightning. These are displayed in a check list, but the user CANNOT uncheck any of the sources. This occurs regardless of how many data sources are listed. Oddly, no errors are captured on the Error Console when you attempt to uncheck on of these things. Reproducible: Always Steps to Reproduce: 1. Install Sunbird or Lightning onto a system where you have Apple iCAL, Evolution, Sunbird 0.2, or the Calendar Extension 2. Start the application in a new profile. 3. The data migrator window will display, showing one of the above data sources are available to import. 4. Attempt to uncheck the selection in the Migration Wizard. Actual Results: User cannot uncheck any of the import sources. Expected Results: User should be able to uncheck any of the import sources. Should be a minor bug. The workaround is to cancel the data migration wizard, thereby not migrating anything.
imo, this blocks 0.5. The dialog is the first thing the user sees, and it having bugs is not a good first impression.
using richlist fixes the problem.
(In reply to comment #1) > imo, this blocks 0.5. Agreed.
Flags: blocking-calendar0.5? → blocking-calendar0.5+
Comment on attachment 252129 [details] [diff] [review] use richlist instead of list This looks very good. Tested it on my mac in Thunderbird beta 2, lightning 2007012203 and I was able to uncheck the migrators. Nice work! ctalbert r+
Attachment #252129 - Flags: first-review?(ctalbert.moz) → first-review+
I like the patch here, but what's the bug? Why doesn't the listbox setup work?
(In reply to comment #5) > I like the patch here, but what's the bug? Why doesn't the listbox setup work? > I understand your point. There's no telling what the actual listbox bug might be, because the original code *should* work. I've searched through the Toolkit->Xul Widgets and the closest item I can find to this issue are the class of "invisible item" bugs in the toolkit: things like 250123. But, these items are always displayed, so that shouldn't be affecting them. Should we create a separate test case and open the bug in Toolkit as well? If so, I think we could still take this patch since it is low risk and we don't have to depend on the fix from toolkit.
(In reply to comment #6) > Should we > create a separate test case and open the bug in Toolkit as well? If so, I > think we could still take this patch since it is low risk and we don't have to > depend on the fix from toolkit. > Yes, and make this bug depend on the toolkit bug, even if we take the patch.
This is an approach that uses listitems. So, listcell seems to be problematic when type=checkbox. jminta: which approach would you prefer?
At the bottom of http://www.xulplanet.com/references/elemref/ref_listcell.html are user contributed notes, which discuss the problem and have a solution.
Comment on attachment 253119 [details] [diff] [review] using listitem this time r=lilmatt Nice job tracking down the real fix.
Comment on attachment 253119 [details] [diff] [review] using listitem this time Fantastic. r2=jminta
Attachment #253119 - Flags: second-review?(jminta) → second-review+
Patch checked in on MOZILLA_1_8_BRANCH and trunk. -> FIXED
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [needs checkin]
Target Milestone: --- → Sunbird 0.5
Verified using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:126.96.36.199pre) Gecko/20070225 Calendar/0.4a1
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.