'self.stopEditing is not a function' while creating an event via drag & drop

RESOLVED FIXED in 1.0b1

Status

defect
P1
major
RESOLVED FIXED
11 years ago
8 years ago

People

(Reporter: martinschroeder, Assigned: martinschroeder)

Tracking

Trunk
1.0b1
Bug Flags:
tb-integration +

Details

Attachments

(1 attachment, 1 obsolete attachment)

I get following error in the Error Console while creating an event in week view via drag'n'drop, but creation of the event works as expected:

Error: self.stopEditing is not a function
Source File: chrome://calendar/content/calendar-view-core.xml
Line: 100

Leaving as unconfirmed because I got this with my own build of Lightning (Windows, comm-central).
I don't see the error using nightly build Lightning 1.0pre (ID: 20081007031722) and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20081007 Shredder/3.0b1pre (ID: 20081007031514).
When using a Zimbra CalDAV server, I see this in my own builds, and, worse, the view refreshes itself and puts the "New Event" summary back.  Turns out the edit actually worked, because forcing the calendars to reload themselves causes the correct summary to re-appear.
Severity: minor → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: tb-integration+
Priority: -- → P1

Updated

11 years ago
Assignee: nobody → Berend.Cornelius
WFM on Mac, maybe fixed in the meantime?
(Assignee)

Comment 4

11 years ago
Confirmed with same error message as in comment#0 using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081121 Lightning/1.0pre Shredder/3.0b1pre.
(Assignee)

Updated

10 years ago
Assignee: berend.cornelius09 → mschroeder
Status: NEW → ASSIGNED
(Assignee)

Updated

10 years ago
OS: Windows XP → All
Hardware: x86 → All
(Assignee)

Comment 5

10 years ago
Posted patch Patch v1 (obsolete) — Splinter Review
After some investigation, I decided to get rid of using the inputField of textbox directly, and the error message has been gone. I had to remove the focus() call, but select() is enough because it also sets the focus.

After more testing, I decided to restore the full textbox behavior of the event boxes. This means to allow setting the cursor through clicking while inline editing. It works in all views for all day and normal events. The trick was to do some mousethrough-magic in the xul stack that builds the event box.
Attachment #380757 - Flags: review?(philipp)
Posted patch Fix - v2Splinter Review
While debitrotting the patch, I also had to do some slight modifications to make sure the gripbar is still accessible. This at least doesn't break anything on linux, I can't test this on windows.
Attachment #380757 - Attachment is obsolete: true
Attachment #383501 - Flags: review+
Attachment #380757 - Flags: review?(philipp)
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/3ed4b7db765e>

-> FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0
These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".
Target Milestone: 1.0 → 1.0b1
You need to log in before you can comment on or make changes to this bug.