I went to msnbc to confirm that autoplaying content was blocked...only to find that the video is set to start playing when you scroll the page, as well. Jesus.
Thanks for all the great work on dev-tools. I recently started developing a chrome extension and found that not all of the great standard functionality was present. Here were some of the main pain points:
- debugger; statements do not work for me
- When right clicking the extension and clicking Inspect Popup, the first few network requests are not reported in the network tab (seems that it starts recording after the extension opens)
- Hot-reloading extension code would be extremely nice
Even just extra documentation on dev-tools with extensions or tips/tricks for debugging extensions would be excellent - I haven't been able to find much in the way of docs. Keep doing the excellent work you're doing, just thought I'd give some suggestions :)
Learning more about Extensions is one of my nagging TODOs. I'll see if our Extensions writer is up for the task, otherwise I'll take a crack at it this quarter. Thanks for the specific feedback.
I have a few things that have been bothering me forever.
Push Notifications Prompts break the back button. Many times I hit a search result on Google, find the page is irrelevant but I can't go back. That's because the page has prompted a push notification. I can't scroll either. It blocks the whole UI. That's very disruptive.
Second, while Postman is wonderful, Chrome's network tab is the super convenient. A very small change to allow replay requests to work via a keyboard shortcut would make a significant impact on the dev cycle. The use-case is to modify the server code then replay the request, rinse, repeat. The alternative is to copy-as-curl or proxy via postman, etc.
Any chance of being able to save the network filter? It takes ages to re-enter a set of filters for request type, source, name etc. on every page refresh, to the point where I've got a bookmarklet so I can at least just copy and paste it in every time.
Are you talking about accessing location, files, camera, and microphone from web browsers? Those are all already possible. For identity, there's various libs and APIs for authenticating with major identity providers. Not sure what you mean by device and app history.
That's the list this browser requires authorization before installation is allowed. Its not about what's possible; its what intrusiveness Chrome demands. Maybe there's a good reason for each one, and the browser will act in good faith.
In order for a website to access camera, microphone, etc., the browser itself needs permission to access those things. The browser prompts you to grant each individual permission to specific sites that request them.
I personally agree though that if you don't want any site to ever have access to camera (for example) there should be a way to install the browser without that permission enabled. Maybe there is? I'm not completely familiar with the iOS / Android / other mobile OS install workflows these days.
Writing to a clipboard when you’re the active tab doesn’t require the prompt, I’d imagine that covers the vast majority of use cases. I can’t think of any good reason why a site should be able to read from the clipboard silently, or write to it in the background.
Prioritizing the use case of the clipboard history web app would ruin the day for many 1Password / LastPass / KeePass etc users.
Automatic password filling isn't great, isn't universal, KeePass's keyboard emulation never worked reliably for me, so users of such apps rely on the clipboard a lot.
And consider that you don't have to give out a password frequently via the clipboard, you only have to do it once with a malicious app nearby.
What I'd like the OS itself to do is to block by default copy/pasting between apps, with the user agreeing to each combination, with "only once" option available.
But sadly, for historical purposes I guess, or maybe because normal users would get annoyed, the OS doesn't do that.
"What I'd like the OS itself to do is to block by default copy/pasting between apps, with the user agreeing to each combination, with "only once" option available."
Please no. At present any application which could compromise you by stealing passwords could probably just as easily pwn your entire system thus you will have saved zero people from harm. Meanwhile 99.9% of people will be frustrated by such an ill thought out security measure. 50% will have to google how to fix clipboard permissions to disable this. 25% will ask their computer literate friends how to do this. 20% will click once every single time and just think the new release of their OS sucks slightly. 10% will accidentally click deny at some point and think cut and paste is broken. Some percentage will probably reinstall their entire OS to fix cut and paste or just hate their life every time they hit this application combination.
Random web pages should probably just never have access to your clipboard because people will just click accept when the malicious site askes. Its sufficient that your browser which you either trust or are already laughably pwned to have access to the clipboard so that you can paste stuff into websites. Said sites don't even need to know the difference between user typed foo and user pasted foo.
> What I'd like the OS itself to do is to block by default copy/pasting between apps, with the user agreeing to each combination, with "only once" option available.
This made me think. At the cost of learning new key combinations, a clipboard manager browser extension could isolate in-browser copy/pastes from the system clipboard, unless explicitly asked.
And yet, I bet there's at least a few dozen people in the world that would fall in love with such a thing, and get viciously angry if you tried to mess with their workflow.
Yup. I updated it for one our web services today, haha. But it was really my mistake. I had received the new cert soon after Google's advisory. :p Consider ass kicked, and lesson learnt to do these things right away, when I earlier today received a mail from a colleague alerting me of Chrome 66 going stable...
Are changes like CSS typed objects a new web standard or Chromium independently making decisions? Can we expect safari/firefox/ie to support this soon or is this only useful if my entire userbase uses chrome?
> Typed OM landed in Chrome 66 and is being implemented in Firefox. Edge has shown signs of support, but has yet to add it to their platform dashboard.
Sigh. What happened to standards? This entire update is a bucket of changes that nobody can use because IE, Firefox, Safari, and mobile are not even close to implementing them.
A google search for "firefox attributeStyleMap" yielded little info about the state of this, but one of the results was a specific commit at a mercurial repository at Mozilla[1], and it seems to be a patch to add this. So perhaps it's much closer than you think?
Edit: Actually, I wasn't paying too much attention to the commit initially. Apparently it's not implementing attributeStyleMap, it's using it as if it exists, so I suppose it's already implemented in this branch, or this is a test in anticipation of it.
No, you've linked a merge commit, which is merging a bunch of stuff.
One of the things it merges is BZ # 1442425 which is landing a newer version of the W3C's set of web platform tests, seen here testing the Typed OM feature you are interested in:
Hmm, so what is the status of this W3C draft[1] (which they say specifically does not imply endorsement), if the W3C is putting a test for it in one of their test suites? Or do Chrome/Chrome devs get commit bits? Or maybe one of the purposes of this is to serve as a way for browsers to coordinate on implementations even before it's become a standard? (It's obviously a way to coordinate on things that are a standard).
Not quite, but new and unproven features are supposed to be hidden behind a runtime flag to prevent a hot mess like what was caused with CSS/JS vendor prefixes.
The Blink team are getting better at this, but they still really need to put their feet on the brakes a little more, and wait until there are at least two implementations ready before flipping their own switch to enable the feature for all of their users.
With two reasonably complete (and independent) implementations it's far more likely that the standard is engine-neutral, and not lacking in crucial detail. The web platform tests will also have been put to the tests to ensure that they have decent coverage. On top of that, the feature can be considered to have been vetted to ensure that it isn't really just being shoved on the web to meet Google's business needs, but rather in the interests of a broader set of people. These things can easily slip if pushed too quickly, even if others are generally supportive of the general idea of the feature.
ie6-style attack on standards was google plan with chrome from day one. their internal moto was something like "reshaping the future" or sone other facist theme I dont recall now
