Elements must be reattached when inserted/removed from top layer
https://bugs.webkit.org/show_bug.cgi?id=105489

Relanding r139402 as rollout due to suspected perf regression did not help (bug 106726).

Reviewed by Julien Chaffraix.

Source/WebCore:

Ensure a reattach occurs when an element is inserted/removed from top layer, so its renderer can be inserted correctly:
as a child of RenderView in top layer sibling order if it's in the top layer, and in the usual place otherwise.

We previously relied on style recalc to catch when an element is inserted/removed from the top layer, because it
only happens on dialog.show/close which toggle display: none. But that is incorrect because, for example, close()
followed immediately by show() results in no style change.

Tests: fast/dom/HTMLDialogElement/removed-element-is-removed-from-top-layer.html
       fast/dom/HTMLDialogElement/top-layer-stacking-correct-order-remove-readd.html

* dom/Element.cpp:
(WebCore::Element::removedFrom): Call Document::removeFromTopLayer to let the element be removed from the top layer vector.
removeFromTopLayer calls Element::setIsInTopLayer(false) itself if needed.
(WebCore::Element::setIsInTopLayer): Ensure a reattach occurs if the element is already attached.

LayoutTests:

* fast/dom/HTMLDialogElement/removed-element-is-removed-from-top-layer-expected.html: Added.
* fast/dom/HTMLDialogElement/removed-element-is-removed-from-top-layer.html: Added.
This tests that a top layer element removed from the document does not reappear in the top layer if readded.
This test actually would pass before this patch, but just by good fortune (see bug).
* fast/dom/HTMLDialogElement/top-layer-stacking-correct-order-remove-readd-expected.html: Added.
* fast/dom/HTMLDialogElement/top-layer-stacking-correct-order-remove-readd.html: Added.
This tests that top layer ordering is correct after removing and readding an element to the top layer.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@140307 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Use ISO8601 date/time formats as fallbacks for date/time input types
https://bugs.webkit.org/show_bug.cgi?id=107418

Reviewed by Kentaro Hara.

We obtain date/time formats from OSes to build date/time input type
UIs. If something wrong happens in the code, fallback formats are
used. Such fallback formats should not be English formats in order that
we can find defects easily.

No new tests. These formats should not be used unless the current code
has defects.

* html/DateTimeInputType.cpp:
(WebCore::DateTimeInputType::setupLayoutParameters):
Use an ISO8601 format which is same as a format used in HTML5.
* html/DateTimeLocalInputType.cpp:
(WebCore::DateTimeLocalInputType::setupLayoutParameters): Ditto.
* html/MonthInputType.cpp:
(WebCore::MonthInputType::setupLayoutParameters): Ditto.
* html/WeekInputType.cpp:
(WebCore::WeekInputType::setupLayoutParameters): Ditto.
* platform/text/LocaleICU.cpp:
(WebCore::LocaleICU::dateFormat): Ditto.
* platform/text/LocaleNone.cpp:
(WebCore::LocaleNone::dateFormat): Ditto.
(WebCore::LocaleNone::dateTimeFormatWithSeconds): Ditto.
(WebCore::LocaleNone::dateTimeFormatWithoutSeconds): Ditto.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@140308 268f45cc-cd09-0410-ab3c-d52691b4dbfc