Closed Bug 448206 Opened 15 years ago Closed 15 years ago
Calendar creation wizard acting weird when creating a calendar with duplicate URI
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:188.8.131.52) Gecko/20080715 Ubuntu/7.10 (gutsy) Firefox/184.108.40.206 Build Identifier: Lightning 0.9pre (2008072418) When testing the overlay of the calendar creation wizard of ThunderBirthDay, I observerd two bugs of the wizard: Reproducible: Always Steps to Reproduce: 1. Create a remote ICS calendar with URI file:///. 2. Try to create another remote ICS calendar with URI file:///. 3. Note that you can advance to customization page (first bug) but you can't advance further. 4. Go back one step and change the URI to file:///bug. 5. Advance to the customization page (it's correct that you're allowed to do that this time). 6. Go back again one step and change the URI to file:/// again (the one that already exists). 7. Pick a name and create the calendar. 8. Open the second calendars properties and note, that its URI is file:///bug (second bug).
(In reply to comment #0) > 1. Create a remote ICS calendar with URI file:///. Ingo, such URLs look rather exotic to me. Why do you think this bug should block the release?
TBD creates calendars at moz-abdirectory:// without anything more. Though of course this in itself is an extension-problem, if it can be solved easily by this patch and it doesn't introduce problems we need this as we want to support TBD imho.
I don't have a problem getting in a fix for that for the release. I just try to understand why it has been proposed for blocking the release. Ingo, do users have to type in such URLs using ThunderBirthDay?
Sorry, maybe I didn't point this out very clearly: The above bugs happen even with TBD deactivated or not installed. They are not related to the extension other than I discovered them when devolopping TBD. The bugs make the calendar creation wizard act unintuitively when rewinding it, changing something and readvancing it. That's why I think that they should be fixed before 0.9.
(In reply to comment #3) > (In reply to comment #0) > > 1. Create a remote ICS calendar with URI file:///. > Ingo, such URLs look rather exotic to me. Why do you think this bug should > block the release? This URL was just un example. The bug happens always if a calendar with a certain URL exists and one tries to add another one with the same URL.
Is there a specific reason why this bug isn't advancing or is it just of low priority?
Ingo, you should ask for review from an appropriate reviewer for both of your patches, cf. http://wiki.mozilla.org/Calendar:Module_Ownership. Maybe you can merge them in one patch for both files for easier checkin.
Personally I think this is not a blocker because the issue exists since several releases (afaik). If you have a final patch that is ready to go into production you'll need to attach it to this bug and request review. See <http://wiki.mozilla.org/Calendar:Build#Creating_a_Patch> and <http://wiki.mozilla.org/Calendar:Module_Ownership>.
Assignee: nobody → ingomu
Flags: blocking-calendar0.9? → blocking-calendar0.9-
I think philipp should be the one to review this.
Comment on attachment 331526 [details] [diff] [review] Sets gCalendar to null when preparing a new calendar. This fixes the second bug. Looks good, r=philipp on both patches.
Attachment #331526 - Flags: review?(Berend.Cornelius) → review+
Attachment #331527 - Flags: review?(Berend.Cornelius) → review+
Checked in on HEAD and MOZILLA_1_8_BRANCH -> FIXED
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → 0.9
Sorry for not knowing how this works and thanks for the links! I'll do it right next time...
Status: RESOLVED → VERIFIED
No problem, don't worry about it :-) You are always encouraged to write patches and if there's anything we can do to make the process easier for you, feel free to contact us.
You need to log in before you can comment on or make changes to this bug.