Should not inherit style from control like element during inserting text just after deleting

Source/core/editing/DeleteSelectionCommand.cpp

 /*
  * Copyright (C) 2005 Apple Computer, Inc.  All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
  * are met:
  * 1. Redistributions of source code must retain the above copyright
  *    notice, this list of conditions and the following disclaimer.
  * 2. Redistributions in binary form must reproduce the above copyright
  *    notice, this list of conditions and the following disclaimer in the
@@ skipping 251 matching lines @@
     // We must pass call parentAnchoredEquivalent on the positions since some editing positions
     // that appear inside their nodes aren't really inside them.  [hr, 0] is one example.
     // FIXME: parentAnchoredEquivalent should eventually be moved into enclosing element getters
     // like the one below, since editing functions should obviously accept editing positions.
     // FIXME: Passing false to enclosingNodeOfType tells it that it's OK to return a non-editable
     // node.  This was done to match existing behavior, but it seems wrong.
     m_startBlock = enclosingNodeOfType(m_downstreamStart.parentAnchoredEquivalent(), &isBlock, CanCrossEditingBoundary);
     m_endBlock = enclosingNodeOfType(m_upstreamEnd.parentAnchoredEquivalent(), &isBlock, CanCrossEditingBoundary);
 }
 
+// We don't want to inherit style from an element which can't have contents.
+static bool shouldNotInheritStyleFrom(const Node& node)
+{
+    return !node.canContainRangeEndPoint();
+}
+
 void DeleteSelectionCommand::saveTypingStyleState()
 {
     // A common case is deleting characters that are all from the same text node. In 
     // that case, the style at the start of the selection before deletion will be the 
     // same as the style at the start of the selection after deletion (since those
     // two positions will be identical). Therefore there is no need to save the
     // typing style at the start of the selection, nor is there a reason to 
     // compute the style at the start of the selection after deletion (see the 
     // early return in calculateTypingStyleAfterDelete).
     if (m_upstreamStart.deprecatedNode() == m_downstreamEnd.deprecatedNode() && m_upstreamStart.deprecatedNode()->isTextNode())
         return;
 
+    if (shouldNotInheritStyleFrom(*m_selectionToDelete.start().anchorNode()))
+        return;
+
     // Figure out the typing style in effect before the delete is done.
     m_typingStyle = EditingStyle::create(m_selectionToDelete.start());
     m_typingStyle->removeStyleAddedByNode(enclosingAnchorElement(m_selectionToDelete.start()));
 
     // If we're deleting into a Mail blockquote, save the style at end() instead of start()
     // We'll use this later in computeTypingStyleAfterDelete if we end up outside of a Mail blockquote
     if (enclosingNodeOfType(m_selectionToDelete.start(), isMailBlockquote))
         m_deleteIntoBlockquoteStyle = EditingStyle::create(m_selectionToDelete.end());
     else
         m_deleteIntoBlockquoteStyle = 0;
@@ skipping 533 matching lines @@
 
 // Normally deletion doesn't preserve the typing style that was present before it.  For example,
 // type a character, Bold, then delete the character and start typing.  The Bold typing style shouldn't
 // stick around.  Deletion should preserve a typing style that *it* sets, however.
 bool DeleteSelectionCommand::preservesTypingStyle() const
 {
     return m_typingStyle;
 }
 
 } // namespace WebCore