GoogleCodeExporter
commented
9 years ago Michael, can you please take a look at this issue? Original comment by vega113 on 18 Apr 2011 at 7:47
- Added labels: ****
- Removed labels: ****
Open GoogleCodeExporter opened 9 years ago
GoogleCodeExporter
commented
9 years ago Michael, can you please take a look at this issue? Original comment by vega113 on 18 Apr 2011 at 7:47
GoogleCodeExporter
commented
9 years ago I found a way to reproduce this exception. It happens while trying to delete an
inline blip while in edit mode.
Original comment by vega113 on 18 Apr 2011 at 9:46
GoogleCodeExporter
commented
9 years ago Yes, I was planning on fixing this this week.
You are correct that the bad state occurs when the blip being edited gets
deleted. Once that happens, any later attempt to restore focus to another blip
will cause a shiny.
The problem is that EditSession needs to be notified if the blip being edited
gets deleted, so it can terminate the edit session in a way that does not crash
on deleted blips. The simple approach of simply listening to the conversation
model for an onBlipDeleted event of the being-edited blip will work 99% of the
time, but it won't work for a compound deletion when the blip being edited is
transitively contained by another object that gets deleted (thread, blip, or
conversation), because the conversation model only broadcasts events for
top-most objects of deleted parts. To handle the compound case requires being
able to examine the deleted object and traverse its contents, in order to see
if the being-edited blip is in there, but structural information of deleted
objects is not reliable due to how document XML deletion works.
An alternative approach is to have the view objects notify listeners if/when
they get detached from the DOM. Again, the transitive case needs to be solved
for that approach.
In short, I think there is a fairly small, direct fix that will solve this
issue except for the very rare cases of compound deletions, which may not be
solvable quickly or nicely. That may be good enough for a long time.
Original comment by hearn...@google.com on 18 Apr 2011 at 2:07
GoogleCodeExporter
commented
9 years ago will do thanks.Original comment by michael.macfadden on 18 Apr 2011 at 2:17
GoogleCodeExporter
commented
9 years ago Has there been a fix on this issue. I am trying to reproduce it and can't seem
to get an exception.Original comment by michael.macfadden on 23 Apr 2011 at 10:13
GoogleCodeExporter
commented
9 years ago Hmm, yep seems like it is gone. Maybe fix for issue 262 solved also this one?Original comment by vega113 on 23 Apr 2011 at 10:35
GoogleCodeExporter
commented
9 years ago
This bug is still easily reproducible:
1. Create a wave.
2. Click Reply on the root blip.
3. Click Delete on the newly created blip.
I'm pretty sure this bug occurs when the you're editing a blip in a reply
thread that has no other siblings, and that reply thread gets deleted.
However, I think my explanation above was way off - it doesn't match the stack
trace, so I don't think the issue is related to edit sessions - it appears
something to do with updating the internal structures that track the anchor
doodads that are used to place threads inline inside the document content of
their parent blip.Original comment by hearn...@google.com on 2 May 2011 at 12:55
GoogleCodeExporter
commented
9 years ago Gah - sorry, I should have updated the corresponding JIRA issue.Original comment by hearn...@google.com on 2 May 2011 at 12:57
Original issue reported on code.google.com by
vega113on 18 Apr 2011 at 7:45