[CSS Shaders] Add WebKitCSSFilterRule to DOMWindow.idl
https://bugs.webkit.org/show_bug.cgi?id=109082

Source/WebCore:

Reviewed by Dean Jackson.

Add an entry for WebKitCSSFilterRuleConstructor in DOMWindow.idl.

Tests: css3/filters/custom-with-at-rule-syntax/parsing-at-rule-invalid.html
       css3/filters/custom-with-at-rule-syntax/parsing-at-rule-valid.html

* page/DOMWindow.idl:

LayoutTests:

Move the at-rule parsing tests to the recently added folder named
"custom-with-at-rule-parsing".

Remove the "custom-filter" prefix from the test filenames to
match the new convention.

Update the tests to use the "shouldHaveConstructor" JS helper function instead of the
"shouldBeType" JS helper function. Among other things, using "shouldHaveConstructor" tests
that window.WebKitCSSFilterRule is defined. "shouldHaveConstructor" has the same
behavior in JSC and V8, unlike "shouldBeType". Therefore, remove the Chromium-specific text
expectation file that was previously needed for "shouldBeType".

Reviewed by Dean Jackson.

* css3/filters/custom-with-at-rule-syntax/parsing-at-rule-invalid-expected.txt: Renamed from LayoutTests/css3/filters/custom/custom-filter-parsing-at-rule-invalid-expected.txt.
* css3/filters/custom-with-at-rule-syntax/parsing-at-rule-invalid.html: Renamed from LayoutTests/css3/filters/custom/custom-filter-parsing-at-rule-invalid.html.
* css3/filters/custom-with-at-rule-syntax/parsing-at-rule-valid-expected.txt: Added.
* css3/filters/custom-with-at-rule-syntax/parsing-at-rule-valid.html: Renamed from LayoutTests/css3/filters/custom/custom-filter-parsing-at-rule-valid.html.
* css3/filters/custom-with-at-rule-syntax/script-tests/parsing-at-rule-invalid.js: Renamed from LayoutTests/css3/filters/script-tests/custom-filter-parsing-at-rule-invalid.js.
(testInvalidFilterAtRule):
* css3/filters/custom-with-at-rule-syntax/script-tests/parsing-at-rule-valid.js: Renamed from LayoutTests/css3/filters/script-tests/custom-filter-parsing-at-rule-valid.js.
(testFilterAtRule):
(testNestedRules):
(checkRule):
* css3/filters/custom/custom-filter-parsing-at-rule-valid-expected.txt: Removed.
* platform/chromium/css3/filters/custom/custom-filter-parsing-at-rule-valid-expected.txt: Removed.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142149 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[BlackBerry] Cookie database isn't loaded into memory in some rare cases
https://bugs.webkit.org/show_bug.cgi?id=109202
PR 286189

Patch by Otto Derek Cheung <otcheung@rim.com> on 2013-02-07
Reviewed by Yong Li.
Internally Reviewed by Konrad Piascik.

If a get/setCookie call is made before the database is loaded, or if there's some
kind of error that causes the loading of the database to fail in the constructor
of CookieManager, the browser will get into a state where it seems like cookie is
permanenty disabled.

Instead of logging the errors and redispatching the setCookie, we should do a force sync
to load the cookie database before continuing.

Since the bug is so difficult to reproduce (I never did so myself), I did the follow test
to make sure the code path is correct:
1) Make sure original implementation is retained - open and loading done in the constructor
2) Removed opening and loading in constructor, the new calls in get/setcookies loaded the db just fine (although with
an initial lag because we are blocking WKT while performing SQLite options).
3) Removed loading in constructor, the new calls loaded the db just fine.

* platform/blackberry/CookieDatabaseBackingStore/CookieDatabaseBackingStore.cpp:
(WebCore::CookieDatabaseBackingStore::openAndLoadDatabaseSynchronously):
(WebCore):
* platform/blackberry/CookieDatabaseBackingStore/CookieDatabaseBackingStore.h:
(CookieDatabaseBackingStore):
* platform/blackberry/CookieManager.cpp:
(WebCore::CookieManager::setCookies):
(WebCore::CookieManager::getCookie):
(WebCore::CookieManager::generateHtmlFragmentForCookies):
(WebCore::CookieManager::getRawCookies):

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