Hi Alex,
I will try to organize a low-end device to do the measurements you are
asking for. Could you please describe how the results would guide your
decision on this issue?
I would also ask you to clarify your concerns. What are the scenarios you
have in mind, and what are the improvements a user would get from this
limit?
When I think of concrete scenarios, then I end up either with the scenario
being unlikely, or that the limit would not make a big difference for the
user experience:
* Unlikely, because it is hard to end up with a big WebAssembly module that
you compile synchronously. You don't write WebAssembly modules by hand, you
generate them with a compiler like Emscripten. The compiler typically does
not only generate the WebAssembly module for you, it also generates the
code for you that downloads and compiles the WebAssembly module. A scenario
where the limit may matter is that the compiler decides to use synchronous
compilation instead of asynchronous compilation. However, why would the
compiler do that?
* Because synchronous compilation provides benefits? What would these
benefits be? The WebAssembly module already gets downloaded asynchronously,
so continuing with synchronous compilation has no advantage to asynchronous
compilation.
* By accident, because the compiler writer does not know better? I
think it's unlikely that a compiler writer would choose to use synchronous
compilation by accident, and that this compiler is then used to produce a
WebAssembly module with 10s of MB, and that the resulting WebAssembly
module is then used in any reasonable webpage.
* The limit would not make a difference for the following reason: On the
website you cite above the average network bandwidth is 9Mbps. Even
compressed the 80MB module in my measurements would take 10s of seconds to
download. Does blocking the main thread of less than 1 second really matter
to the user after they waited many times as long for the download?
As I wrote before, I understand why this limit was introduced originally.
However, these reasons don't exist anymore, and all that remains is a spec
violation, see https://webassembly.github.io/spec/js-api/index.html#limits.
Even a limit of 10MB is still a spec violation, and as I wrote before, I
don't see any justification for that.
Cheers, Andreas
On Thu, Apr 20, 2023 at 8:58 PM Alex Russell <slightly...@chromium.org>
wrote:
> Thanks for the document, Andreas.
>
> The numbers in it are still hugely concerning, and I'm a -1 until and
> unless we have data from P75-P90 Androids and Windows devices. Our
> telemetry from Edge shows that nearly half of users are on slow, spinning
> rust and 2-4 core devices, and the only system in your test list that
> reflects something in this range is the N2840 in the HP Chromebook 13 G1.
>
> Motivations in the document regarding testing are not compelling. Folks
> doing testing can provide flags to the browser (which you could expose to
> raise the limit without an Intent).
>
> Would you be willing to accept a higher cap? Your document suggests that
> ~10MiB (unzipped) might be reasonable, but would want to see data from
> low-end Android before going even that far.
>
> Thanks.
>
> On Thursday, April 20, 2023 at 4:06:30 AM UTC-7 Yoav Weiss wrote:
>
>> LGTM2
>>
>> Thanks for testing this! :)
>>
>> On Thu, Apr 20, 2023 at 12:58 PM Andreas Haas <ah...@google.com> wrote:
>>
>>> Hi Philip, Yoav,
>>>
>>> I added a test to the wasm spec tests now, see
>>> https://github.com/WebAssembly/spec/pull/1642. It creates modules of
>>> size 1GB and 1GB+1 and checks that compilation passes or fails,
>>> respectively. The modules consist of a single custom section, so that
>>> minimal processing time and module creation time should be introduced.
>>>
>>> As far as I know, the other browsers never had a special limit on the
>>> module size, other than the spec'ed 1GB limit. I confirmed that now with
>>> Firefox.
>>>
>>> Cheers, Andreas
>>>
>>> On Wed, Apr 19, 2023 at 5:59 PM Philip Jägenstedt <foo...@chromium.org>
>>> wrote:
>>>
>>>> Hey Andreas,
>>>>
>>>> Do you know what the limits of other browsers are? If testing a 1 GB
>>>> module is too slow to be reliable (sometimes timing out) then perhaps
>>>> there's a large-ish module you can test with that still exceeds the current
>>>> limits?
>>>>
>>>> Note that you could also add a manual test in WPT for the real limit (1
>>>> GB) and run it at least once manually to ensure it works the same in all
>>>> browsers.
>>>>
>>>> Best regards,
>>>> Philip
>>>>
>>>> On Mon, Apr 17, 2023 at 12:12 PM 'Andreas Haas' via blink-dev <
>>>> blink-dev@chromium.org> wrote:
>>>>
>>>>> Hi Ian,
>>>>>
>>>>> Here is the benchmark: x20.corp.google.com/users/ah/ahaas/index.html
>>>>>
>>>>> You need corp access for it, and I didn't have access to low tier
>>>>> Android phones with corp access.
>>>>>
>>>>> Safari also compiles lazily, so their compile times are similar to
>>>>> ours. Firefox compiles modules eagerly, and therefore takes longer. I
>>>>> don't
>>>>> really have the devices or the setup to do the measurements on other
>>>>> browsers. I measured the performance of Firefox on my workstation, where
>>>>> the compilation of the 80MB module takes slightly less than 1.6 seconds.
>>>>> This is about 60% slower than Chrome with eager compilation. I tried
>>>>> Chrome
>>>>> with eager compilation on the atlas Chromebook. Compilation of the 80MB
>>>>> module takes 2.8 seconds there.
>>>>>
>>>>> Cheers, Andreas
>>>>>
>>>>> On Fri, Apr 14, 2023 at 8:18 PM Ian Kilpatrick <
>>>>> ikilpatr...@chromium.org> wrote:
>>>>>
>>>>>> Out of curiosity -
>>>>>> What is performance like on a low tier Android phone (I see only a
>>>>>> Pixel 7 tested above)?
>>>>>> What is the performance of your benchmark on other browsers - across
>>>>>> device classes? (Even if they don't have this limit - this intent will
>>>>>> mean
>>>>>> that it'll be interoperable to use the sync method - potentially causing
>>>>>> compat problems for the other browsers).
>>>>>>
>>>>>> Ian
>>>>>>
>>>>>> On Fri, Apr 14, 2023 at 2:00 AM 'Andreas Haas' via blink-dev <
>>>>>> blink-dev@chromium.org> wrote:
>>>>>>
>>>>>>> Hi Alex,
>>>>>>>
>>>>>>> Here are the performance numbers that I collected:
>>>>>>> https://docs.google.com/document/d/1hOGwCurQmPF_GZdflsJno286sJXgfoLeOGaUhZuMzCQ/edit?usp=sharing
>>>>>>>
>>>>>>> I think the question is more, how can we justify such a limit? I
>>>>>>> mean, I agree, it is not a good experience if the main thread is blocked
>>>>>>> for 1 second, but we have to consider the scenario in which this is
>>>>>>> happening. The main thread is blocked for one second after a WebAssembly
>>>>>>> module was downloaded which is tens of megabytes big.
>>>>>>>
>>>>>>> Additionally, in the current environment it is not likely that you
>>>>>>> end up serving a big WebAssembly module to the user with synchronous
>>>>>>> compilation by accident. WebAssembly modules are typically generated by
>>>>>>> compilers which also generate the JS glue code around it. These
>>>>>>> compilers
>>>>>>> produce glue code that uses asynchronous compilation or even streaming
>>>>>>> compilation. Therefore a developer would have to make an effort to even
>>>>>>> serve a big WebAssembly module with synchronous compilation.
>>>>>>>
>>>>>>> There are scenarios where developers make this effort, and I don't
>>>>>>> think we should prevent developers when they make this conscious
>>>>>>> decision.
>>>>>>> One such scenario is tests. It is much easier to write and run tests
>>>>>>> with
>>>>>>> synchronous compilation. We run nearly all our WebAssembly tests in V8
>>>>>>> with
>>>>>>> synchronous compilation. We also got bug reports repeatedly where
>>>>>>> developers struggle with their tests because of the 4KB limit.
>>>>>>>
>>>>>>> So overall I think the limit was justified in the beginning, but now
>>>>>>> with lazy compilation and baseline compilation this justification is
>>>>>>> gone.
>>>>>>> I don't think this limit makes the web a better place anymore, it just
>>>>>>> makes the life of developers difficult in specific niche situations.
>>>>>>>
>>>>>>> Cheers, Andreas
>>>>>>>
>>>>>>> On Thu, Apr 13, 2023 at 8:21 PM Alex Russell <
>>>>>>> slightly...@chromium.org> wrote:
>>>>>>>
>>>>>>>> "Below 1 second" for something that can block the main thread is
>>>>>>>> not particularly heartening. Can you please provide the histogram data
>>>>>>>> you're seeing to justify this? Would you be happy to raise the cap to a
>>>>>>>> larger (but still fixed) size based on a baseline device config
>>>>>>>> instead?,
>>>>>>>> e.g.:
>>>>>>>>
>>>>>>>> https://infrequently.org/2022/12/performance-baseline-2023/
>>>>>>>>
>>>>>>>> Best,
>>>>>>>>
>>>>>>>> Alex
>>>>>>>> On Wednesday, April 5, 2023 at 7:09:15 AM UTC-7 Andreas Haas wrote:
>>>>>>>>
>>>>>>>>> Hi Yoav,
>>>>>>>>>
>>>>>>>>> I'm not sure what you mean. At the moment this 4KB limit exists in
>>>>>>>>> Chrome, but it does not exist in Safari or Firefox. I tested this
>>>>>>>>> locally
>>>>>>>>> on my Macbook. I don't know if there exists another test at the moment
>>>>>>>>> which passes on Safari and Firefox but fails on Chrome, and would
>>>>>>>>> pass on
>>>>>>>>> Chrome after we remove the limit.
>>>>>>>>>
>>>>>>>>> Cheers, Andreas
>>>>>>>>>
>>>>>>>>> On Wed, Apr 5, 2023 at 3:57 PM Yoav Weiss <yoavwe...@chromium.org>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Apr 5, 2023 at 3:05 PM 'Andreas Haas' via blink-dev <
>>>>>>>>>> blink-dev@chromium.org> wrote:
>>>>>>>>>>
>>>>>>>>>>> Contact emailsah...@google.com
>>>>>>>>>>>
>>>>>>>>>>> ExplainerNone
>>>>>>>>>>>
>>>>>>>>>>> SpecificationNone
>>>>>>>>>>>
>>>>>>>>>>> Summary
>>>>>>>>>>>
>>>>>>>>>>> There exists a limit on the size of a module that can be
>>>>>>>>>>> compiled with `new WebAssembly.Module()` on the main thread. This
>>>>>>>>>>> limit is
>>>>>>>>>>> 4KB, and it was introduced when WebAssembly modules got compiled
>>>>>>>>>>> eagerly
>>>>>>>>>>> with an optimizing compiler, which could block the main thread for
>>>>>>>>>>> many
>>>>>>>>>>> seconds and even minutes. In the meantime V8 launched lazy
>>>>>>>>>>> compilation for
>>>>>>>>>>> WebAssembly modules, and the execution time of `new
>>>>>>>>>>> WebAssembly.Module()`
>>>>>>>>>>> is below 1 second even for the biggest modules we see, even on the
>>>>>>>>>>> weakest
>>>>>>>>>>> devices we measured. Therefore it is time to remove this limit.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Blink componentBlink>JavaScript>WebAssembly
>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EJavaScript%3EWebAssembly>
>>>>>>>>>>>
>>>>>>>>>>> TAG reviewNone
>>>>>>>>>>>
>>>>>>>>>>> TAG review statusNot applicable
>>>>>>>>>>>
>>>>>>>>>>> Risks
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Interoperability and Compatibility
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> *Gecko*: Shipped/Shipping
>>>>>>>>>>>
>>>>>>>>>>> *WebKit*: Shipped/Shipping
>>>>>>>>>>>
>>>>>>>>>>> *Web developers*: Strongly positive We received repeated bug
>>>>>>>>>>> reports because of this limit. Especially for tests synchronous
>>>>>>>>>>> compilation
>>>>>>>>>>> with `new WebAssembly.Module()` is useful, but the size limit
>>>>>>>>>>> prevents
>>>>>>>>>>> bigger tests from using synchronous compilation.
>>>>>>>>>>>
>>>>>>>>>>> *Other signals*:
>>>>>>>>>>>
>>>>>>>>>>> WebView application risks
>>>>>>>>>>>
>>>>>>>>>>> Does this intent deprecate or change behavior of existing APIs,
>>>>>>>>>>> such that it has potentially high risk for Android WebView-based
>>>>>>>>>>> applications?
>>>>>>>>>>>
>>>>>>>>>>> None
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Debuggability
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Will this feature be supported on all six Blink platforms
>>>>>>>>>>> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
>>>>>>>>>>> Yes
>>>>>>>>>>>
>>>>>>>>>>> Is this feature fully tested by web-platform-tests
>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>>>>>>>>>> ?No
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Is it interoperably tested by other means? I'm not super familiar
>>>>>>>>>> with WASM testing..
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Flag name
>>>>>>>>>>>
>>>>>>>>>>> Requires code in //chrome?False
>>>>>>>>>>>
>>>>>>>>>>> Estimated milestones
>>>>>>>>>>> Shipping on desktop 114
>>>>>>>>>>> Shipping on Android 114
>>>>>>>>>>> Shipping on WebView 114
>>>>>>>>>>>
>>>>>>>>>>> Anticipated spec changes
>>>>>>>>>>>
>>>>>>>>>>> Open questions about a feature may be a source of future web
>>>>>>>>>>> compat or interop issues. Please list open issues (e.g. links to
>>>>>>>>>>> known
>>>>>>>>>>> github issues in the project for the feature specification) whose
>>>>>>>>>>> resolution may introduce web compat/interop risk (e.g., changing to
>>>>>>>>>>> naming
>>>>>>>>>>> or structure of the API in a non-backward-compatible way).
>>>>>>>>>>> None
>>>>>>>>>>>
>>>>>>>>>>> Link to entry on the Chrome Platform Status
>>>>>>>>>>> https://chromestatus.com/feature/5080569152536576
>>>>>>>>>>>
>>>>>>>>>>> Links to previous Intent discussions
>>>>>>>>>>>
>>>>>>>>>>> This intent message was generated by Chrome Platform Status
>>>>>>>>>>> <https://chromestatus.com/>.
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>>
>>>>>>>>>>> Andreas Haas
>>>>>>>>>>>
>>>>>>>>>>> Software Engineer
>>>>>>>>>>>
>>>>>>>>>>> ah...@google.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Google Germany GmbH
>>>>>>>>>>>
>>>>>>>>>>> Erika-Mann-Straße 33
>>>>>>>>>>>
>>>>>>>>>>> 80636 München
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Geschäftsführer: Paul Manicle, Liana Sebastian
>>>>>>>>>>>
>>>>>>>>>>> Registergericht und -nummer: Hamburg, HRB 86891
>>>>>>>>>>>
>>>>>>>>>>> Sitz der Gesellschaft: Hamburg
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise
>>>>>>>>>>> erhalten haben sollten, leiten Sie diese bitte nicht an jemand
>>>>>>>>>>> anderes
>>>>>>>>>>> weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie
>>>>>>>>>>> mich bitte
>>>>>>>>>>> wissen, dass die E-Mail an die falsche Person gesendet wurde.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This e-mail is confidential. If you received this communication
>>>>>>>>>>> by mistake, please don't forward it to anyone else, please erase
>>>>>>>>>>> all copies
>>>>>>>>>>> and attachments, and please let me know that it has gone to the
>>>>>>>>>>> wrong
>>>>>>>>>>> person.
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> You received this message because you are subscribed to the
>>>>>>>>>>> Google Groups "blink-dev" group.
>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from
>>>>>>>>>>> it, send an email to blink-dev+unsubscr...@chromium.org.
>>>>>>>>>>> To view this discussion on the web visit
>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAELSTve0zdDNeCDXvG%3D73-zVy8Fps_9eFErWfOocSfxbzOxGHQ%40mail.gmail.com
>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAELSTve0zdDNeCDXvG%3D73-zVy8Fps_9eFErWfOocSfxbzOxGHQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>>>>>>> .
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> Andreas Haas
>>>>>>>>>
>>>>>>>>> Software Engineer
>>>>>>>>>
>>>>>>>>> ah...@google.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Google Germany GmbH
>>>>>>>>>
>>>>>>>>> Erika-Mann-Straße 33
>>>>>>>>>
>>>>>>>>> 80636 München
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Geschäftsführer: Paul Manicle, Liana Sebastian
>>>>>>>>>
>>>>>>>>> Registergericht und -nummer: Hamburg, HRB 86891
>>>>>>>>>
>>>>>>>>> Sitz der Gesellschaft: Hamburg
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise
>>>>>>>>> erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes
>>>>>>>>> weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich
>>>>>>>>> bitte
>>>>>>>>> wissen, dass die E-Mail an die falsche Person gesendet wurde.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This e-mail is confidential. If you received this communication by
>>>>>>>>> mistake, please don't forward it to anyone else, please erase all
>>>>>>>>> copies
>>>>>>>>> and attachments, and please let me know that it has gone to the wrong
>>>>>>>>> person.
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Andreas Haas
>>>>>>>
>>>>>>> Software Engineer
>>>>>>>
>>>>>>> ah...@google.com
>>>>>>>
>>>>>>>
>>>>>>> Google Germany GmbH
>>>>>>>
>>>>>>> Erika-Mann-Straße 33
>>>>>>>
>>>>>>> 80636 München
>>>>>>>
>>>>>>>
>>>>>>> Geschäftsführer: Paul Manicle, Liana Sebastian
>>>>>>>
>>>>>>> Registergericht und -nummer: Hamburg, HRB 86891
>>>>>>>
>>>>>>> Sitz der Gesellschaft: Hamburg
>>>>>>>
>>>>>>>
>>>>>>> Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise
>>>>>>> erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes
>>>>>>> weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich
>>>>>>> bitte
>>>>>>> wissen, dass die E-Mail an die falsche Person gesendet wurde.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> This e-mail is confidential. If you received this communication by
>>>>>>> mistake, please don't forward it to anyone else, please erase all copies
>>>>>>> and attachments, and please let me know that it has gone to the wrong
>>>>>>> person.
>>>>>>>
>>>>>>> --
>>>>>>> You received this message because you are subscribed to the Google
>>>>>>> Groups "blink-dev" group.
>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>> send an email to blink-dev+unsubscr...@chromium.org.
>>>>>>> To view this discussion on the web visit
>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAELSTvcq5b4gz6U3SYBjPkU1jCZtaPnNZr9tDsD8fZxG7w8Hvg%40mail.gmail.com
>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAELSTvcq5b4gz6U3SYBjPkU1jCZtaPnNZr9tDsD8fZxG7w8Hvg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>>> .
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Andreas Haas
>>>>>
>>>>> Software Engineer
>>>>>
>>>>> ah...@google.com
>>>>>
>>>>>
>>>>> Google Germany GmbH
>>>>>
>>>>> Erika-Mann-Straße 33
>>>>>
>>>>> 80636 München
>>>>>
>>>>>
>>>>> Geschäftsführer: Paul Manicle, Liana Sebastian
>>>>>
>>>>> Registergericht und -nummer: Hamburg, HRB 86891
>>>>>
>>>>> Sitz der Gesellschaft: Hamburg
>>>>>
>>>>>
>>>>> Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise
>>>>> erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes
>>>>> weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich
>>>>> bitte
>>>>> wissen, dass die E-Mail an die falsche Person gesendet wurde.
>>>>>
>>>>>
>>>>>
>>>>> This e-mail is confidential. If you received this communication by
>>>>> mistake, please don't forward it to anyone else, please erase all copies
>>>>> and attachments, and please let me know that it has gone to the wrong
>>>>> person.
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "blink-dev" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to blink-dev+unsubscr...@chromium.org.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAELSTvfdj1exWfsUYs4RjbSc7WOTTpNyb1aXCA0R3uPQzCci6w%40mail.gmail.com
>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAELSTvfdj1exWfsUYs4RjbSc7WOTTpNyb1aXCA0R3uPQzCci6w%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>>
>>>
>>> --
>>>
>>> Andreas Haas
>>>
>>> Software Engineer
>>>
>>> ah...@google.com
>>>
>>>
>>> Google Germany GmbH
>>>
>>> Erika-Mann-Straße 33
>>>
>>> 80636 München
>>>
>>>
>>> Geschäftsführer: Paul Manicle, Liana Sebastian
>>>
>>> Registergericht und -nummer: Hamburg, HRB 86891
>>>
>>> Sitz der Gesellschaft: Hamburg
>>>
>>>
>>> Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten
>>> haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter,
>>> löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen,
>>> dass die E-Mail an die falsche Person gesendet wurde.
>>>
>>>
>>>
>>> This e-mail is confidential. If you received this communication by
>>> mistake, please don't forward it to anyone else, please erase all copies
>>> and attachments, and please let me know that it has gone to the wrong
>>> person.
>>>
>>>
--
Andreas Haas
Software Engineer
ah...@google.com
Google Germany GmbH
Erika-Mann-Straße 33
80636 München
Geschäftsführer: Paul Manicle, Liana Sebastian
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten
haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter,
löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen,
dass die E-Mail an die falsche Person gesendet wurde.
This e-mail is confidential. If you received this communication by mistake,
please don't forward it to anyone else, please erase all copies and
attachments, and please let me know that it has gone to the wrong person.
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAELSTvc6QoyFWYAhsCh9eSvOvpu0JpgEPSn2UuKLZRNOKsyAGg%40mail.gmail.com.
