googlechrome / samples Goto Github PK
View Code? Open in Web Editor NEWA repo containing samples tied to new functionality in each release of Google Chrome.
Home Page: https://www.chromestatus.com/samples
License: Apache License 2.0
A repo containing samples tied to new functionality in each release of Google Chrome.
Home Page: https://www.chromestatus.com/samples
License: Apache License 2.0
@jeffposnick Do you mind if I take over this simple one?
Moving the discussion from #206
The benefits would be that it's generally a best practice, and it would make it easier to run ESLint
and JSCS
against the .js
files directly, without having to extract them from the generated HTML. Now that we're on a Jekyll build for the site, we have a lot more flexibility.
The drawbacks would be that the View Source... experience is arguably worse for developers who want to learn about new features in context, since they'd have to match up what's going on with an external JavaScript file with the rest of the content on the main page.
The drawback might be mitigated by inlining the entire external .js
file's source on the main page wrapped in a <div class="hightlight">
, like we're currently doing for explicitly tagged snippets of the inline JavaScript source.
There's also the topic of whether we should do the same for CSS files. There are a handful of samples out there just demonstrate CSS functionality.
Thinking a bit more about use cases for window.caches
that don't involve service workers (see #103), I remembered that the cache-then-network example that @jakearchibald describes could make for a good standalone example.
This is a placeholder issue for us to write a sample for the Web App Manifest demonstrating usage. Mounir recently landed this. Although not yet in a public build, Chrome Android will use the Web Manifest for the "Add to homescreen" feature.
Spec: http://w3c.github.io/manifest/
Rough samples:
manifest.json
{
"name": "2048 app",
"icons": [{
"src": "icon/lowres",
"sizes": "64x64",
"type": "image/webp"
}, {
"src": "icon/hd_small",
"sizes": "64x64"
}, {
"src": "icon/hd_hi",
"sizes": "128x128",
"density": "2"
}],
"start_url": "/index.html",
"display": "fullscreen",
"orientation": "landscape"
}
index.html
<!doctype>
<html>
<title>My app</title>
<!-- Startup configuration -->
<link rel="manifest" href="manifest.json">
Intent to Ship:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/EbAMnvBUU80
Commits:
https://chromium.googlesource.com/chromium/src/+/b225ae560fea0648b61fad36b5972221a7f5c47d
https://chromium.googlesource.com/chromium/src/+/f60720832599bc7306d9e37e3cef5ceee4c224ce
https://chromium.googlesource.com/chromium/src/+/96297a73c48ff299e45eac62b967a8e333569602
https://chromium.googlesource.com/chromium/src/+/9317a291b84457b9a8feb8ecd94d0593bb0fff9b
first argument of Response
constructor is a BodyInit
and, this defined like this.
typedef (Blob or BufferSource or FormData or URLSearchParams or USVString) BodyInit;
so we can send JSON.stringify ed string of object without wrapping Blob.
at least, chrome canary 42 works fine with it.
It should demonstrate basic registration, and then an onfetch
handler that returns hardcoded data in response to requests that match specific criteria.
An example would be intercepting all requests for a specific API call and instead of fetch()
ing them, returning a hardcoded JSON document.
(This would be useful within the context of unit testing code that relies on API responses.)
It should demonstrate basic registration, and then have the client page send specific requests to the SW script via postMessage()
on the client page/the onmessage
handler in the SW script.
For the purposes of this example they could be simple strings that are echoed back, but in the real world a useful case would be to send a request from the client page to the SW to cache a URL or to update some sort of SW configuration.
Reminder to scrub all the samples to use consistent capitalization—they're "service worker(s)", not "Service Worker(s)" or "ServiceWorker(s)".
It should demonstrate basic registration, and then an onfetch
handler that selectively caches responses based on multiple criteria:
example.com
)image/*
resposnes). Subsequent requests for the same URL are served from the cache.Until the native Caches API is available, it should use https://github.com/coonsta/cache-polyfill
Either explain why a port was used or change the demo to use postMessage().
https://chromium.googlesource.com/v8/v8/+/74c381221c93253bbee513aa2539d93269303b8b
Landed behind a flag for now, but we can write a sample and unflag when it goes stable. Code from tweet if useful at all.
This sample: https://github.com/GoogleChrome/samples/tree/gh-pages/push-messaging-and-notifications
I've double-checked this.
I've added -v to the curl command and confirmed that GCM is returning 200 OK. I've put a break point in the first line of onpush and confirmed that it's never reached.
None of the existing service worker examples illustrate how to properly version the caches and clean up old caches. They should be updated to do that.
Object.assign() now makes it easy for developers to clone or merge objects by copying all the values of enumerable properties from one or more source objects to a target object.
in the demo https://googlechrome.github.io/samples/media-hover-pointer/ it reads
if a user is on a tablet with a connected a mouse, 'any-pointer' will be satisfied. If the mouse is then removed, the browser will report 'any-pointer' as none.
Maybe I'm misunderstanding the spec, but why would/should any-pointer
be none
once the mouse is removed? wouldn't the fact that the touchscreen interface is still present count as a pointer device?
There's an enormous amount of boilerplate HTML (and some JS + CSS) that used in every sample. I'm guilty of encouraging a copy/paste model that got us to this point.
Moving to a model in which we took advantage of GitHub's Jekyll support and abstracted away most of the boilerplate into a shared template would make a lot of sense. Samples that needed to do something that didn't fit into the template would still have the flexibility to commit a full set of HTML + JS + CSS.
I think it would also be possible to automate generating an index page as part of this process, closing #37
event.waitUntil won't currently wait for all assets to attempt to cache.
Its a subtle issue, but essentially a large number or big assets may hit a condition where the SW is terminated in the background.
Returning the addAll promise should fix this:
The page states it's using a 1x1 pixel, but is actually using a 2x2 pixel PNG.
It would be preferable to have something more flexible than a single output area at the top that all the JS snippets log to.
See the discussion at #163
That lists all the samples.
It should demonstrating registration in which data from the client page is encoded as a URL parameter appended to the SW script URL. The SW then deserializes that URL parameter data and makes use of it.
An example would be a client page that passes in a list of URLs that should be prefetched, as an alternative to a hardcoded a list of prefetch URLs within the SW's oninstall
handler.
It should demonstrate basic registration, and then an onfetch
handler that returns default data when the fetch()
request fails.
A potential example would be to fetch()
an API call that will always fail (such as a YouTube Data API v3 request that omits an API key and returns a HTTP 403) and return a fallback JSON document in its place.
It's been suggested in the past (by @gauntface I believe) to include a top-level jscs
configuration in this repo. It might be difficult to automatically enforce the styles, but including a reference that folks could opt into would do some good.
It should demonstrate standard registration with a technique for immediately elevating the installing SW to be the controlling SW. (I think this would entail forcing the page to refresh, but it would be good to confirm the best practice first.)
I've launched the app install banner sample pages on Chrome for Android 44.0.2 (tried the latest Dev + Beta builds from the Play store). After enabling chrome://flags/#bypass-app-banner-engagement-checks
and relaunching Chrome, I still don't see any banner.
Any ideas? Note: I'm not signed into Chrome, is this a requirement?
/cc @PaulKinlan
Specifically, here: https://github.com/GoogleChrome/samples/search?utf8=%E2%9C%93&q=innerText
A+ that it works in Chrome regardless, but for those of us creepin' via FF...we'd sure <3 textContent instead.
It should demonstrate basic registration, and then an onfetch
handler that automatically caches all responses. Subsequent requests for the same URL are served from the cache.
Until the native Caches API is available, it should use https://github.com/coonsta/cache-polyfill
I have a session token in my page that I want to use in my SW.
I'm using postMessage to send it to the SW and then plan on using IDB to store it there.
A small sample that stores bits of (non-response) data persistently would be pretty nice, imho.
It should demonstrate standard registration and prefetching/caching a list of URLs within the oninstall
handler.
https://github.com/GoogleChrome/samples/tree/gh-pages/generators a lot of the other es-6 feature end in es-6.
cc @jeffposnick
It might be a good idea to merge these repos at some point in the future.
These are following a sync with Peter a week or so ago. We've since opted to ship a single larger sample in #79, but these could still be useful to explore when time allows.
At minimum I would suggest we go for the minimal options in https://github.com/google/web-starter-kit/blob/master/app/basic.html, if not the full layout options in https://github.com/google/web-starter-kit/blob/master/app/index.html.
basic.html support would just mean a few minor new additions atm. cc @PaulKinlan
Need to include:
http://googlechrome.github.io/samples/beacon/
Uncaught SyntaxError: Unexpected token ( line 77
Two perf API's have been updated to work in a worker context (SW and WW) create some demos that show this working.
CSS Motion Paths have landed in Chrome Canary. Created a test here: https://output.jsbin.com/rigoxo we will need an article and sample for M46
In file samples/push-messaging-and-notifications/main.js
Line 174: navigator.serviceWorker.ready.then(function(serviceWorkerRegistration) {
serviceWorker is never ready if you do a "hard reload" (shift-reload icon) or "empty cache and hard reload"
Chrome version 44.0.2403.39 beta-m (64-bit)
Test: try it at https://widgetsign.com/chrome_samples/push-messaging-and-notifications/
Fault: the button is never enabled if you do a shift-reload.
It was, it is not anymore.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.