Closed Bug 397788 Opened 17 years ago Closed 17 years ago

autocomplete fails at first with auto bcc, this.view.selection has no properties, autocomplete.xml line: 1541

Categories

(MailNews Core :: Composition, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: eyalroz1, Assigned: neil)

References

Details

Attachments

(2 files, 1 obsolete file)

When I compose a new message, and start entering text in the 'To' field, autocomplete doesn't trigger and the error console says: Error: this.view.selection has no properties Source file: chrome://global/content/autocomplete.xml Line: 1541 If I delete the 'To' line and create another one, autocomplete does work. I'm using sm trunk 2007-09-22. This has been happening for a while now, probably several months. I have a BCC line by deault.
Summary: autocomplete fails at first → autocomplete fails at first with auto bcc, chrome://global/content/autocomplete.xml line: 1541
I see this in thunderbird trunk 2007-10-01-08Z linux
OS: Windows XP → All
Summary: autocomplete fails at first with auto bcc, chrome://global/content/autocomplete.xml line: 1541 → autocomplete fails at first with auto bcc, this.view.selection has no properties, autocomplete.xml line: 1541
clearSelection() was introduced in bug 79069.
Attached patch proposed fix (obsolete) — Splinter Review
This fixes it for me.
Assignee: nobody → mkmelin+mozilla
Status: NEW → ASSIGNED
Attachment #283563 - Flags: superreview?(neil)
Attachment #283563 - Flags: review?(kairo)
I get a boatload of frame construction assertions, but what seems to be happening here is that although we're setting the view on the tree box object there's no frame yet in this case to create the selection for us. We therefore need to ask the box object for the tree back and it will then hook up the new frame which includes creating a selection for us. See nsTreeBoxObject::GetView particularly the comment // Our new frame needs to initialise itself.
Assignee: mkmelin+mozilla → neil
Attachment #283563 - Attachment is obsolete: true
Attachment #283602 - Flags: review?(jag)
Attachment #283563 - Flags: superreview?(neil)
Attachment #283563 - Flags: review?(kairo)
Comment on attachment 283602 [details] [diff] [review] Bullet-proof selection This seems a rather fragile way to solve this problem. Someone's bound to optimize the "unnecessary" |tree.| away. Can we maybe make |view| a getter/setter around |tree.view|, or is that too slow? Maybe we can add a |selection| getter/setter that does the "Need to ensure selection exists by reading tree.view first" step, with a comment along those lines? Is there any way to fix this in the view implementations so that the JS code doesn't have to worry about this?
Attachment #283986 - Flags: review?(jag)
Blocks: 304309
Comment on attachment 283986 [details] [diff] [review] Explicit selection I guess I can live with this.
Attachment #283986 - Flags: review?(jag) → review+
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Magnus in comment #3 > clearSelection() was introduced in bug 79069. are you saying this is a regression of 79069? Or only related? (patch wasn't checked in til 2007-08-25) I see a symptom that enter won't add new new address lines and this doesn't depend on auto bcc. Don't know if this has same cause as this bug. version 3.0a1pre (2007100604) Error: this.view.selection has no properties Source File: chrome://global/content/autocomplete.xml Line: 1484
Line 1484 was one of the lines that I patched...
Ah yes, it was only moved. (I guess no relation then.)
Attachment #283602 - Flags: review?(jag)
Product: Core → MailNews Core
Pushed by frgrahl@gmx.net: https://hg.mozilla.org/comm-central/rev/c377e77c7836 Ensure the tree selection exists before trying to do things to it b=397788 r=jag
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: