Add support for languagechange event: - https://html.spec.whatwg.org/#dom-navigator-languages
Created attachment 291184 [details] Patch
Created attachment 291185 [details] Patch
Comment on attachment 291185 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=291185&action=review > Source/WebCore/page/DOMWindow.cpp:426 > + > + addLanguageChangeObserver(this, &languagesChangedCallback); This would be racy with regards with the cache being invalidated in FontGenericFamilies. We need to either force invalidating the cache in there first or add some other mechanism to make sure this observer is called at the very end or very first so that there is no observable race conditions.
Comment on attachment 291185 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=291185&action=review >> Source/WebCore/page/DOMWindow.cpp:426 >> + addLanguageChangeObserver(this, &languagesChangedCallback); > > This would be racy with regards with the cache being invalidated in FontGenericFamilies. > We need to either force invalidating the cache in there first > or add some other mechanism to make sure this observer is called at the very end or very first > so that there is no observable race conditions. Sorry, I do not understand your comment at all. I see that FontGenericFamilies is also registering a language change callback but I do not understand how this impacts Window registering its own callback. Which cache are you referring to?
Comment on attachment 291185 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=291185&action=review >>> Source/WebCore/page/DOMWindow.cpp:426 >>> + addLanguageChangeObserver(this, &languagesChangedCallback); >> >> This would be racy with regards with the cache being invalidated in FontGenericFamilies. >> We need to either force invalidating the cache in there first >> or add some other mechanism to make sure this observer is called at the very end or very first >> so that there is no observable race conditions. > > Sorry, I do not understand your comment at all. I see that FontGenericFamilies is also registering a language change callback but I do not understand how this impacts Window registering its own callback. > Which cache are you referring to? Oh, I think I understand your worry now. How about we simply fire the JS event asynchronously?
(In reply to comment #5) > Comment on attachment 291185 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=291185&action=review > > >>> Source/WebCore/page/DOMWindow.cpp:426 > >>> + addLanguageChangeObserver(this, &languagesChangedCallback); > >> > >> This would be racy with regards with the cache being invalidated in FontGenericFamilies. > >> We need to either force invalidating the cache in there first > >> or add some other mechanism to make sure this observer is called at the very end or very first > >> so that there is no observable race conditions. > > > > Sorry, I do not understand your comment at all. I see that FontGenericFamilies is also registering a language change callback but I do not understand how this impacts Window registering its own callback. > > Which cache are you referring to? > > Oh, I think I understand your worry now. How about we simply fire the JS > event asynchronously? Yeah, that works too.
Created attachment 291223 [details] Patch
Comment on attachment 291223 [details] Patch Clearing flags on attachment: 291223 Committed r207040: <http://trac.webkit.org/changeset/207040>
All reviewed patches have been landed. Closing bug.