Clean up js-test-post.js remainders.

r161289 deleted js-test-post.js, so this CL cleans up.

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

git-svn-id: svn://svn.chromium.org/blink/trunk@162227 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Reland "Split the frame tree logic out of HistoryItem".

This patch introduces HistoryEntry, which is basically a wrapper around
a tree of HistoryNodes. HistoryNode contains a HistoryItem (which
stores the relevant data for the frame) and a vector of child
HistoryNodes. Multiple HistoryNodes can hold references to the same
HistoryItem. HistoryEntry/HistoryNode have logic for doing a parital
clone of themselves while replacing the navigated item.

HistoryEntry keeps 2 maps. One maps frame ids (which are new) to
HistoryNodes, the other maps FrameTree::uniqueName() to HistoryNodes. The
frame id maps is sufficient for the vast majority of cases, but a secondary
mechanism for finding a HistoryNode is necessary when doing a back/forward
navigation with iframes, as child iframes may want to load from history, but
the HistoryEntry may not know about the new Frame object yet.

HistoryController know lives in Page, though for simplicity I left a helper
on FrameLoader that gets the Page's HistoryController.

This patch doesn't plumb the new data model all the way out, so
HistoryController retains a mechanic for converting between the old
HistoryItem child tree and the HistoryEntry tree.

BUG=

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

git-svn-id: svn://svn.chromium.org/blink/trunk@162228 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Upgrade parser-created Custom Elements in creation order.

Originally, parser-created Custom Elements were upgraded in reverse
order (which quickly and dirtily ensured that an element's children
were upgraded before the element itself.) Then we rethought this and
upgraded them post-order (which meant an element's children were still
upgraded before the element itself, but siblings were upgraded in
order.)

Now parser-created Custom Elements are upgraded in creation order (ie
pre-order.) This is consistent with how Custom Elements are upgraded
when cloning a subtree of nodes.

This is described here:
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=23778>

BUG=234509

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

git-svn-id: svn://svn.chromium.org/blink/trunk@162229 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Make generation IDs of animated GIF and webp frames unique.

Re-landing https://codereview.chromium.org/65713004/

In some cases GIFImageDecoder::initFrameBuffer/WEBImageDecoder::initFrameBuffer
copy the content of the previous frame as the starting state for the current
frame. The generation ID of the two bitmaps is identical after that copy. We
need to call SkBitmap::notifyPixelsChanged to make sure that the new frame
gets a unique generation ID.

R=hclam@chromium.org,reveman@chromium.org,reed@chromium.org,enne@chromium.org,zmo@chromium.org
BUG=307689

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

git-svn-id: svn://svn.chromium.org/blink/trunk@162230 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Auto-rebaseline for r162212

http://src.chromium.org/viewvc/blink?view=revision&revision=162212

BUG=319541
TBR=senorblanco@chromium.org

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

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