6 ms·

Yeah that Chrome experience doesn't sound great. Fwiw I tend to put my test cases on jsbin or Glitch, but yeah, a Chrome engineer should know to put the page on

Yeah that Chrome experience doesn't sound great. Fwiw I tend to put my test cases on jsbin or Glitch, but yeah, a Chrome engineer should know to put the page on a basic web server. If anyone runs into problems like this, feel free to bug one of the Chrome dev rel folks, such as me.

MatthewPhillips 8y ago
Like I said, my impression is that often the people replying are not engineers. Here's one with that problem: https://bugs.chromium.org/p/chromium/issues/detail?id=674096#c8 https://bugs.chromium.org/p/chromium/issues/detail?id=674096...
- jaffathecake 8y ago
  Yeah, that's not great, but the commenter in #12 is a senior engineer on devtools, so at least the right person saw it in the end.
  - bjornstar 8y ago
    https://bugs.chromium.org/p/chromium/issues/detail?id=674096#c12 https://bugs.chromium.org/p/chromium/issues/detail?id=674096... was an assignment 6 months ago. It's still open after 2.5 years. I would not call this a good outcome.
    - jaffathecake 8y ago
      Sure, but priorities are a thing. I don't think it's fair to compare this to an origin model exploit.
      - MatthewPhillips 8y ago
        Yeah, this is a UI bug in devtools for a feature not a lot of people use. Plus web worker bugs always get pushed to the bottom of the queue for every browser. So I don't have any problem with how long my weird issues take to get fixed. It's more about comparing to Firefox where you usually get a quick response which at least conveys that the person on the other end understands what is being reported. I'm fine with the eventual outcome here. A comment acknowledging that it's a real bug (or not) would have been better, but being assigned to someone sort of acknowledges that, I guess.
        oblio 8y ago
        > Plus web worker bugs always get pushed to the bottom of the queue for every browser. Why is that?
        philipwhiuk 8y ago
        It's pretty rare to use in user-code. It might be well used in libraries, but I guess the standard developer experience is using libraries not writing them.
        abritinthebay 8y ago
        Of course it’s rare because it’s unreliable and buggy as shit across browsers atm (tho a lot better than it was). So... somewhat self-fulfilling
        Rodd45 8y ago
        They should take this kind of bugs seriously.
    - gsnedders 8y ago
      What would you rather happen? Browser vendors hire more people such that they can fix every valid bug ever filed?
      - reitanqild 8y ago
        Maybe. A first good step would be if the billion dollar company would try to come up to the standard of the non profit.
        earenndil 8y ago
        *trillion dollar company.
  - contras1970 8y ago
    <soapbox> looking at that ticket, the response from google is catastrophic. the guy or gal handling the ticket has no idea about web browsers. the reporter shows up with a complete reproducer and the best google manages is throw clueless screenshots (for a brief fully textual error message no less!) at them? they've already done a bunch of your work for free. get your ass off the heap of money, ffs! </soapbox> edit: oh, and i lower my hat to you for coming here and taking the heat. appreciated, having a real person to vent at is so special in the case of google...
    - mrunkel 8y ago
      To be fair, the screenshot does provide additional info, like the fact that they are using file://.. It's often better to include more in a screenshot than less. I would imagine that the chromium teams probably gets a lot of tickets. That means they need a lot of bodies to triage them. It's not like any Sr. Dev ist going to be jumping at that job.
      - Rodd45 8y ago
        Yeah, it seems they need to take this issue seriously. Could be a way for hackers as well.
paulddraper 8y ago
I have an S3 bucket for mine. E.g. a js closure memory leak: https://bugs.chromium.org/p/chromium/issues/detail?id=315190 https://bugs.chromium.org/p/chromium/issues/detail?id=315190 https://s3.amazonaws.com/chromebugs/memory.html https://s3.amazonaws.com/chromebugs/memory.html
- myfonj 8y ago
  Whoa, that page crashed my (long running) Nightly (presumably exhausted RAM completely) and in freshly started got 4 GB for the tab process (and survived). Nice.
reitanqild 8y ago
> If anyone runs into problems like this, feel free to bug one of the Chrome dev rel folks, such as me. Hi, and thanks for being part of creating Chrome && reaching out here. Now that I have a Chrome guy here maybe you can help with another annoying issues: -QC internally at Google seems to be blissfully unaware of the fact that other browsers exists. Examples: - one glaring issue I'm running into in core Angular on a daily basis. - Google Calendar performance is sometimes unreasonably slow in Firefox - For weeks or months Google search results would drive once CPU core to 100% twice a minute.
- notatoad 8y ago
  none of those are something a chrome dev rel person can help you with. People like you are the reason we have to deal with three layers of low-level tech support before we can actually talk to somebody who knows what they're doing - please don't just spray your random complaints at anybody who happens to be related to google in any way.
  - gsnedders 8y ago
    And it's not like the Chrome dev rel team doesn't fight for these things, but ultimately the Chrome team doesn't have any control of prioritisation of bugs in other products (like Calendar). The only way we're going to see a significant change is when those high up in the Google org chart start caring about products working well in other browsers; as long as it's up to each individual product we'll continue to see products prioritising time-to-market and targeting only the browser with the majority of the market.
    - reitanqild 8y ago
      That's the second reason to post it here: because if you see one googler there are hundreds nearby, and some of them might be at the relevant team. (And if I point out often enough what happened last time a mega corp abused their position to market their browser then maybe some of them starts talking about it internally?)
  - 8y ago

MatthewPhillips 8y ago

Like I said, my impression is that often the people replying are not engineers. Here's one with that problem: https://bugs.chromium.org/p/chromium/issues/detail?id=674096#c8 https://bugs.chromium.org/p/chromium/issues/detail?id=674096...

jaffathecake 8y ago
Yeah, that's not great, but the commenter in #12 is a senior engineer on devtools, so at least the right person saw it in the end.
- bjornstar 8y ago
  https://bugs.chromium.org/p/chromium/issues/detail?id=674096#c12 https://bugs.chromium.org/p/chromium/issues/detail?id=674096... was an assignment 6 months ago. It's still open after 2.5 years. I would not call this a good outcome.
  - jaffathecake 8y ago
    Sure, but priorities are a thing. I don't think it's fair to compare this to an origin model exploit.
    - MatthewPhillips 8y ago
      Yeah, this is a UI bug in devtools for a feature not a lot of people use. Plus web worker bugs always get pushed to the bottom of the queue for every browser. So I don't have any problem with how long my weird issues take to get fixed. It's more about comparing to Firefox where you usually get a quick response which at least conveys that the person on the other end understands what is being reported. I'm fine with the eventual outcome here. A comment acknowledging that it's a real bug (or not) would have been better, but being assigned to someone sort of acknowledges that, I guess.
      - oblio 8y ago
        > Plus web worker bugs always get pushed to the bottom of the queue for every browser. Why is that?
        philipwhiuk 8y ago
        It's pretty rare to use in user-code. It might be well used in libraries, but I guess the standard developer experience is using libraries not writing them.
        abritinthebay 8y ago
        Of course it’s rare because it’s unreliable and buggy as shit across browsers atm (tho a lot better than it was). So... somewhat self-fulfilling
        Rodd45 8y ago
        They should take this kind of bugs seriously.
  - gsnedders 8y ago
    What would you rather happen? Browser vendors hire more people such that they can fix every valid bug ever filed?
    - reitanqild 8y ago
      Maybe. A first good step would be if the billion dollar company would try to come up to the standard of the non profit.
      - earenndil 8y ago
        *trillion dollar company.
- contras1970 8y ago
  <soapbox> looking at that ticket, the response from google is catastrophic. the guy or gal handling the ticket has no idea about web browsers. the reporter shows up with a complete reproducer and the best google manages is throw clueless screenshots (for a brief fully textual error message no less!) at them? they've already done a bunch of your work for free. get your ass off the heap of money, ffs! </soapbox> edit: oh, and i lower my hat to you for coming here and taking the heat. appreciated, having a real person to vent at is so special in the case of google...
  - mrunkel 8y ago
    To be fair, the screenshot does provide additional info, like the fact that they are using file://.. It's often better to include more in a screenshot than less. I would imagine that the chromium teams probably gets a lot of tickets. That means they need a lot of bodies to triage them. It's not like any Sr. Dev ist going to be jumping at that job.
    - Rodd45 8y ago
      Yeah, it seems they need to take this issue seriously. Could be a way for hackers as well.

paulddraper 8y ago

I have an S3 bucket for mine. E.g. a js closure memory leak: https://bugs.chromium.org/p/chromium/issues/detail?id=315190 https://bugs.chromium.org/p/chromium/issues/detail?id=315190 https://s3.amazonaws.com/chromebugs/memory.html https://s3.amazonaws.com/chromebugs/memory.html

myfonj 8y ago
Whoa, that page crashed my (long running) Nightly (presumably exhausted RAM completely) and in freshly started got 4 GB for the tab process (and survived). Nice.

reitanqild 8y ago

> If anyone runs into problems like this, feel free to bug one of the Chrome dev rel folks, such as me. Hi, and thanks for being part of creating Chrome && reaching out here. Now that I have a Chrome guy here maybe you can help with another annoying issues: -QC internally at Google seems to be blissfully unaware of the fact that other browsers exists. Examples: - one glaring issue I'm running into in core Angular on a daily basis. - Google Calendar performance is sometimes unreasonably slow in Firefox - For weeks or months Google search results would drive once CPU core to 100% twice a minute.

notatoad 8y ago
none of those are something a chrome dev rel person can help you with. People like you are the reason we have to deal with three layers of low-level tech support before we can actually talk to somebody who knows what they're doing - please don't just spray your random complaints at anybody who happens to be related to google in any way.
- gsnedders 8y ago
  And it's not like the Chrome dev rel team doesn't fight for these things, but ultimately the Chrome team doesn't have any control of prioritisation of bugs in other products (like Calendar). The only way we're going to see a significant change is when those high up in the Google org chart start caring about products working well in other browsers; as long as it's up to each individual product we'll continue to see products prioritising time-to-market and targeting only the browser with the majority of the market.
  - reitanqild 8y ago
    That's the second reason to post it here: because if you see one googler there are hundreds nearby, and some of them might be at the relevant team. (And if I point out often enough what happened last time a mega corp abused their position to market their browser then maybe some of them starts talking about it internally?)
- 8y ago