88043 2012-05-31 21:33:21 -0700 Author Shadow DOM should be disabled in contenteditable temporarily. 2012-06-21 10:33:30 -0700 1 1 1 Unclassified WebKit HTML Editing 528+ (Nightly build) Unspecified Unspecified RESOLVED WONTFIX P2 Normal --- 1 shinyak webkit-unassigned dglazkov dominicc hayato morrita rniwa tasak oldest_to_newest 638956 0 shinyak 2012-05-31 21:33:21 -0700 When Shadow DOM is attached in contenteditable, it causes a lot of crashes while editing. To make Shadow DOM go further, we should consider disabling Author Shadow DOM temporarily. Adding User Agent Shadow DOM, which is used for <input>, <textarea>, <meter>, etc, should be OK though. Note that we should be able to enable Author Shadow DOM for debugging in DRT! 638958 1 rniwa 2012-05-31 21:42:30 -0700 (In reply to comment #0) > When Shadow DOM is attached in contenteditable, it causes a lot of crashes while editing. I don't think that's an acceptable solution. We can't disable a bunch of features that don't work well inside shadow DOM arbitrarily. We need to fix editing code to work well with shadow DOM. 638968 2 shinyak 2012-05-31 22:03:33 -0700 (In reply to comment #1) > (In reply to comment #0) > > When Shadow DOM is attached in contenteditable, it causes a lot of crashes while editing. > > I don't think that's an acceptable solution. We can't disable a bunch of features that don't work well inside shadow DOM arbitrarily. We need to fix editing code to work well with shadow DOM. I understand it, but... We're just thinking a kind of alternative plan. 639445 3 dglazkov 2012-06-01 09:33:26 -0700 (In reply to comment #2) > (In reply to comment #1) > > (In reply to comment #0) > > > When Shadow DOM is attached in contenteditable, it causes a lot of crashes while editing. > > > > I don't think that's an acceptable solution. We can't disable a bunch of features that don't work well inside shadow DOM arbitrarily. We need to fix editing code to work well with shadow DOM. > > I understand it, but... > > We're just thinking a kind of alternative plan. I think we should discuss this idea first. I am kind of ambivalent about what's the right thing to do here. We did this with disabling author shadows on inputs, and now we nearly trained the few peeps who experiment with shadow DOM that inputs are not usable with shadow DOM, which seems like a bad thing. On the other hand, we don't want to be crashing like drunk monkeys in ferraris. Let's put it this way: I am confident in your abilities to climb HTML editing learning curve and identify the root issues (I am sure there are only a few of those) and fix this in a reasonable timeframe :) 639532 4 rniwa 2012-06-01 11:15:35 -0700 (In reply to comment #3) > I think we should discuss this idea first. I am kind of ambivalent about what's the right thing to do here. We did this with disabling author shadows on inputs, and now we nearly trained the few peeps who experiment with shadow DOM that inputs are not usable with shadow DOM, which seems like a bad thing. On the other hand, we don't want to be crashing like drunk monkeys in ferraris. Right, this is not a desirable solution if we want a good consistent API for the Web and want other browser vendors to implement it :) For example, why would Microsoft or Mozilla should disable contenteditable in their shadow DOM if their editing code was much more sound than ours? > Let's put it this way: I am confident in your abilities to climb HTML editing learning curve and identify the root issues (I am sure there are only a few of those) and fix this in a reasonable timeframe :) I'm more than happy to look at those crashes if you guys can send a list of crashes with stack trace & reduction. 654670 5 rniwa 2012-06-21 10:33:30 -0700 Probably not.