search

hitrust / wave-protocol

Automatically exported from code.google.com/p/wave-protocol
0 stars 0 forks source link

creating a new wave then deleting the first blip gives a shiny #157

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. click on 'new wave'
2. click on 'delete' in the first blip
3. click on another wave

What is the expected output? What do you see instead?
expected : either the wave is deleted or the wave stay empty
instead I get a shiny (see below)

What version of the product are you using? On what operating system?
22a32302d6  w/ memory stores on Ubuntu 8.04.3 LTS (server) 

Please provide any additional information below.

shiny stack trace :

Stack trace:

One or more exceptions caught, see full set in UmbrellaException#getCauses
  Unknown.sE (Unknown source:0)
  Unknown.FE (Unknown source:0)
  Unknown.uU (Unknown source:0)
  Unknown.jU (Unknown source:0)
  Unknown.OT (Unknown source:0)
  Unknown.lEb (Unknown source:0)
  Unknown.rQ (Unknown source:0)
Caused by: One or more exceptions caught, see full set in 
UmbrellaException#getCauses
  Unknown.sE (Unknown source:0)
  Unknown.FE (Unknown source:0)
  Unknown.uU (Unknown source:0)
  Unknown.jU (Unknown source:0)
  Unknown.OT (Unknown source:0)
  Unknown.Lgc (Unknown source:0)
  Unknown.GQ (Unknown source:0)
Caused by: Component not found: MENU
  Unknown.sE (Unknown source:0)
  Unknown.EE (Unknown source:0)
  Unknown.t_d (Unknown source:0)
  Unknown.l$d (Unknown source:0)
  Unknown.q$d (Unknown source:0)
  Unknown.UOd (Unknown source:0)
  Unknown.lOd (Unknown source:0)

Original issue reported on code.google.com by jola...@gmail.com on 17 Nov 2010 at 9:15

GoogleCodeExporter commented 9 years ago 
FYI, if you build the web client with:
  ant compile_gwt_dev
then the stack trace you get will have meaningful names.

The cause of this error is that when switching away from a wave, the teardown 
logic attempts to end the current editing session, which fails if the blip 
tracked by the edit session is no longer attached to the page.

This bug also occurs if someone else deletes a blip that you are editing, and 
then you open another wave.

One fix for this would be to make the EditSession observe Conversation events.  
In particular, to take note of blip/thread deletions, and determine if the 
focused/edited blip is within the subtree of any deleted part of the 
conversation, and recover gracefully.

Original comment by hearn...@google.com on 17 Nov 2010 at 9:50

GoogleCodeExporter commented 9 years ago 
The assessment in the previous comment is correct, however I would also add 
some additional thougts.

It might be possible that we want to disallow deleting the first blip in the 
root conversation thread.  This is what Google Wave does (at least it appears 
that you can not delete the first blip).  I am not sure if the first blip in 
the root thread should be treated special like this or not.  Generally the 
content of the fist blip seems to be treaded as the premise of the conversation 
(i.e. it appears in the digest / wave list as the title of the wave).

An alternative to this rule might be that you can not delete a blip if it the 
only blip in the root conversation.  The sublte difference being that if you 
create a wave and then add a second blip, that you would then be able to delete 
the first blip.  The second blip would then become the only blip in the wave 
and therefore be non-deletable.

In either scenario the result would be that a wave generally always contains at 
least one blip in the root thread.

Is this something we want to do.  If so I can take care if implementing it as a 
fix to this issue.

Original comment by michael.macfadden on 18 Nov 2010 at 8:55

GoogleCodeExporter commented 9 years ago 
That you couldn't delete the first (only) blip in a wave was a flaw in Google 
Wave which we worked towards addressing. It shouldn't be treated specially. 
With a reply box, a wave is still perfectly functional with no blips.

The special case made it impossible to delete private replies, so that's one 
motivation for generally allowing the first blip to be deleted. A user can't 
necessarily see the root wavelet of a conversation, so it also doesn't warrant 
special handling.

Original comment by ano...@google.com on 18 Nov 2010 at 10:58

GoogleCodeExporter commented 9 years ago 
Alright, that makes sense.  Thanks for the clarification.  One side not would 
be that its a bit weird to have a "reply" box on a page that has nothing to 
reply to.  We could figure that subtly out, though.. possibly just change the 
text of the reply box under that scenario.

Original comment by michael.macfadden on 18 Nov 2010 at 11:54