Node cannot be inserted at the specified point in attendees dialog

RESOLVED FIXED in 1.5

Status

Calendar
Dialogs
--
blocker
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: Fallen, Assigned: Paenglab)

Tracking

Lightning 1.5

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

6 years ago
I've had 2 user reports of this error when opening the atendees dialog. This is said to happen in 1.6b1 and 1.5 (and maybe earlier).

uncaught exception: [Exception... "Node cannot be inserted at the specified point in the hierarchy" code: "3" nsresult: "0x80530003 (HierarchyRequestError)" location: "chrome://calendar/content/calendar-event-dialog-attendees.js Line: 85"]

Also, while we are at it:

Warning: Error in parsing value for 'min-height', Declaration dropped. chrome://calendar/skin/calendar-event-dialog.css.
(Assignee)

Comment 1

6 years ago
(In reply to Philipp Kewisch [:Fallen] from comment #0)
> Also, while we are at it:
> 
> Warning: Error in parsing value for 'min-height', Declaration dropped.
> chrome://calendar/skin/calendar-event-dialog.css.

This was fixed in Bug 758529 for Lightning 1.7. Maybe this can be pushed to 1.6.

Comment 2

6 years ago
Might be related to or be the cause of bug 765501 and bug 765530.

Comment 3

6 years ago
Thunderbird 12 + Lightning 1.4 doesn't show the error message. 
Therefore either caused by a change in Thunderbird 13 or Lightning 1.5.
(Reporter)

Comment 4

6 years ago
I got another email and was told the user has downgraded Lightning from 1.6b1 / 1.5.1 to 1.5, where the issue doesn't show up. I guess its that one patch we slipped in to 1.5.1...

Updated

6 years ago
Blocks: 765530
(Reporter)

Comment 5

6 years ago
At least 4 more reports via email. It is indeed the bug we slipped in, bug 762861. Due to the @import rule being added, the style rule in calendar-event-dialog-attendees.css line 85 can't be inserted due to being at the wrong place.

Two options here:

* Backout the bug we slipped in
* Attempt to fix it, possibly forcing insertation at the end of the stylesheet.
Severity: normal → blocker

Comment 6

6 years ago
Bug 762861 is only a cosmetic issue. I'd suggest to backout the patch on all branches to restore functionality and reopen Bug 762861 for a proper and tested fix.
(Assignee)

Comment 7

6 years ago
Created attachment 634074 [details] [diff] [review]
patch

Sorry to make such troubles. This patch reverts the change and adds the css  through the manifest. I tested it under 1.5.1 and it works without the nasty bug.
Attachment #634074 - Flags: review?(philipp)
(Reporter)

Comment 8

6 years ago
Comment on attachment 634074 [details] [diff] [review]
patch

How much tested is that patch? I can't test it since I'm now also having compile issues on windows.

I'm going to defer to Stefan to decide if we should rather backout or push this fix for 1.5.2.
Attachment #634074 - Flags: review?(philipp) → review?(ssitter)
(Assignee)

Comment 9

6 years ago
I tested it under XP and Win7. Invited a person and checked the icons in customize window on different toolbars.

Comment 10

6 years ago
Comment on attachment 634074 [details] [diff] [review]
patch

For a quick 1.5.2 bug fix release I'd prefer to just backout the causing patch.

All other calendar-windows overlay in the modified jar.mn use os=WINNT. 
Why is it not required for the new added line?
(Assignee)

Comment 11

6 years ago
Created attachment 634569 [details] [diff] [review]
Patch with os=WINNT

(In reply to Stefan Sitter from comment #10)
> Comment on attachment 634074 [details] [diff] [review]
> patch
> 
> All other calendar-windows overlay in the modified jar.mn use os=WINNT. 
> Why is it not required for the new added line?

Because the lines are in a #ifdef XP_WIN they only apply to Windows so  os=WINNT isn't really needed. But for the future with one XPI for all platforms it's better now set and makes then in the future no problems.
Attachment #634074 - Attachment is obsolete: true
Attachment #634074 - Flags: review?(ssitter)
Attachment #634569 - Flags: review?(ssitter)

Updated

6 years ago
Attachment #634569 - Flags: review?(ssitter)
Attachment #634569 - Flags: review+
Attachment #634569 - Flags: approval-calendar-release?
Attachment #634569 - Flags: approval-calendar-beta?
Attachment #634569 - Flags: approval-calendar-aurora?
Assignee: nobody → richard.marti
Status: NEW → ASSIGNED
(Reporter)

Comment 12

6 years ago
Comment on attachment 634569 [details] [diff] [review]
Patch with os=WINNT

Hmm so I guess you requesting approval for release means you think we can take the patch regardless of what you said in comment 10?
Attachment #634569 - Flags: approval-calendar-release?
Attachment #634569 - Flags: approval-calendar-release-
Attachment #634569 - Flags: approval-calendar-beta?
Attachment #634569 - Flags: approval-calendar-beta+
Attachment #634569 - Flags: approval-calendar-aurora?
Attachment #634569 - Flags: approval-calendar-aurora+
(Reporter)

Comment 13

6 years ago
Comment on attachment 634569 [details] [diff] [review]
Patch with os=WINNT

Hmm so I guess you requesting approval for release means you think we can take the patch regardless of what you said in comment 10?
Attachment #634569 - Flags: approval-calendar-release- → approval-calendar-release+
(Reporter)

Comment 14

6 years ago
comm-central changeset 8cce5c4cbec8
releases/comm-aurora changeset 6773e229f26c
releases/comm-beta changeset 47897e195a21
releases/comm-release changeset e6750a3ba0f6
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
(Reporter)

Updated

6 years ago
Target Milestone: --- → 1.5
You need to log in before you can comment on or make changes to this bug.