Remove the Custom Element registration context null object.

core calls the Custom Element registration context at fewer points
now, so the null registration context isn't really pulling its weight.

BUG=247219
R=morrita@chromium.org

Review URL: https://codereview.chromium.org/19810005

git-svn-id: svn://svn.chromium.org/blink/trunk@154878 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Remove the last uses of Missing in TestExpectations.  Missing no longer makes sense with the auto-rebaseliner

R=ojan,adamk

Review URL: https://chromiumcodereview.appspot.com/20191002

git-svn-id: svn://svn.chromium.org/blink/trunk@154879 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Remove a couple of dead client redirect functions in WebFrameTestProxy

BUG=257316

Review URL: https://chromiumcodereview.appspot.com/20177002

git-svn-id: svn://svn.chromium.org/blink/trunk@154880 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Do not normalize into NFC the values of form fields

This commit renames the TextEncoding::encode(const String&, UnencodableHandling) const
API function to normalizeAndEncode() to make clear that the function
first applies Unicode NFC normalization before encoding the string. All
existing references to encode() except for one were updated to call
normalizeAndEncode() instead.

TextEncoding::encode(const String&, UnencodableHandling) const is added
back as a new API function which only encodes the string, but does not
normalize the string before encoding.

The one call to the old encode() function that was not updated is in
FormDataList::appendString(const String&). This was left as a call to
the new encode() to fix Issue 117128.

Chrome and Safari are unlike other browsers in that they apply Unicode
NFC normalization to form values when submitting a form; in particular,
the following browsers were tested and found not to normalize the form
values:
- Firefox 22.0
- Firefox ESR 17.0.7
- Opera 12.16
- IE 6
- IE 7
- IE 8
- IE 9
- IE 10
- Amaya 11.4.7

NFC normalization actually changes the meaning of text in certain scripts.
Notably, there are certain Biblical Hebrew words for which normalization
causes the word to be erroneously encoded. One example is given on page 9
of the SBL Hebrew Font User Manual version 1.5:
http://www.sbl-site.org/Fonts/SBLHebrewManualv1.5.pdf
This example is added as the new form-data-encoding-3.html layout test.

BUG=117128

Review URL: https://chromiumcodereview.appspot.com/19845004

git-svn-id: svn://svn.chromium.org/blink/trunk@154881 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Add Ian Vollick to core/OWNERS.

Review URL: https://chromiumcodereview.appspot.com/20152003

git-svn-id: svn://svn.chromium.org/blink/trunk@154882 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Add a Blink API to set window features on a WebView.

This will allow for re-creating a popup with correct window features
after we've decided to block the popup and not create it previously.

With the old popup blocking behavior, the new WebView was just hidden,
and we never had to set the features manually.

BUG=38458
R=abarth@chromium.org

Review URL: https://chromiumcodereview.appspot.com/19804008

git-svn-id: svn://svn.chromium.org/blink/trunk@154883 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Move runin to original position when sibling element is destroyed. Additionally, if If moveRunInUnderSiblingBlockIfNeeded is called when the sibling run-in block is being destroyed, it means that the run-in is moving to original position and we do not need to do nothing.

R=
BUG=260388

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=154557

Review URL: https://chromiumcodereview.appspot.com/19290002

git-svn-id: svn://svn.chromium.org/blink/trunk@154884 bbb929c8-8fbe-4397-9dbb-9b2b20218538