Coder Social home page Coder Social logo

devtools-docs's Introduction

Read only!

You're looking at the previous home of the official Chrome DevTools documentation on developer.chrome.com (aka "DCC").

New docs

Head over to the new DevTools homepage for updated docs and tutorials and contribute by submitting pull requests to the WebFundamentals repository.


Legacy instructions

Contributing

Please see the contributing.md file.

Additional DevTools docs

Covered in the DevTools Content Inventory

Deployment

Once pushed to master, updates will go live to the DCC site within a few minutes or so.

Troubleshooting

  • Make sure you've created CLs with any imported GH changes.
  • If you can't find the content with the devtools-docs repo, it might be part of the Chromium repo
    • CSS, JavaScript, and navigation bugs related to developer.chrome.com can be logged to the Chromium issue tracker

License

Except as otherwise noted, the content of the DevTools documentation is licensed under the Creative Commons Attribution 3.0 License, and code samples are licensed under the Apache 2.0 License.

devtools-docs's People

Contributors

addyosmani avatar arthurvr avatar atdt avatar davidcalhoun avatar deepak1556 avatar dickvdbrink avatar dr4b avatar evverx avatar fangjue avatar garbee avatar heatheramahan avatar jakub-g avatar jaredwilli avatar jpmedley avatar kaycebasques avatar kdzwinel avatar mathiasbynens avatar meggin avatar nathan avatar paulirish avatar pbakaus avatar pearlchen avatar phistuck avatar poziworld avatar rob--w avatar samccone avatar sandipchitale avatar umaar avatar wellingguzman avatar wonglok avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

devtools-docs's Issues

Settings updates

The settings need to be updated so they include new ones and don't include old ones no longer there.

Documentation of HTTP Remote Debugging API

I was browsing the source of Chromium to learn more about the HTTP Remote Debugging API in Chrome, as I've been unable to find documentation for this API.

Is it intentionally left undocumented, or should an effort be started to document this AP?

/k

More shortcuts to add

Just wanted to record these before I forgot about them...

Styles sidebar:
Cmd+Click on property
Cmd+Click on value

Screencast:
Opt+Scroll and
Cmd+two finger click drag to zoom

Emulation:
Shift+Scroll to zoom

Incorrect shortcuts in doc:
Cmd+D to delete line in Sources

Emulation doc

  • no more overrides
  • new hot stuff. details forthcoming

Create a priority label and assign to docs issues

We're seeing some really fantastic ideas posted for new docs on the tracker.

Now that we're using it to manage what we're working on it would be great to assign priority labels to them so the team know what needs to be completed first. It might also be useful for community members interested in getting involved.

We could go for ['low','medium','high'] or ['P0','P1','P2'] etc.

@paulirish wdyt?

New new new!

We got some feedback from engineering that we can do a better job highlighting what's new and changed in the docs.

image

That includes:

  • making use of above navigation badges
  • calling out newness/changes at the top of the docs
  • preferring new content at the top vs old (js profiling content before flame chart, erg)

But it's always important to make people consider the docs fresh and not stale. So let's do that not just with updated imagery, but with more explicit callouts to what is new.

Any suggestions come to mind?

chrome.devtools.inspectedWindow.reload({ preprocessorScript })

The Chrome Devtools JavaScript preprocessor intercepts JavaScript just before it enters V8, the Chrome JS system, allowing the JS to be transcoded before compilation. In combination with page injected JavaScript, the preprocessor allows a complete synthetic runtime to be constructed in JavaScript.

(basically, it's crazy awesome)

It's most documented over here: https://code.google.com/p/chromium/wiki/ScriptPreprocessor

Test here: debugger-script-preprocessor.html and debugger-script-preprocessor-expected.html

And sample extension is shared on here: http://developer.chrome.com/extensions/samples (search for prepro)

We need this properly documented over at http://developer.chrome.com/extensions/devtools_inspectedWindow#method-reload

Tips and tricks updates

There's a number of typos and incorrect things on the tips and tricks page now.

Search for typos:
function cals
hten

And the mentions of ? for keyboard shortcuts are not right, since that opens the general settings. There's a couple places it mentions using it to view shortcuts on this page.

There's a couple other things too that aren't a thing anymore i noticed too. Will have to relook to see what tho

LiveEdit complexity demo

below is a dump of data about how LiveEdit works and its limitations and some pretty wild demos to show it's power.

there is additional info in a thread (between peter and jjb that could be useful to surface. i can share with those interested.


Hi guys

To illustrate core concepts of LiveEdit and discuss how we can make LiveEdit more obvious for user, I hacked together a small demo site:

http://peter.rybin.spb.ru/liveedit_demo/index.html (couldn't find better place to host it quickly).

It shows what really happens when the script is edited live. The demo program has a simple Factory function, that produce an instance of nested function, which we should call "closure", since it binds variables from its outer scope:

( URL = http://peter.rybin.spb.ru/liveedit_demo/scripting.js )

var closure_list = [];

function Factory(p, q) {
    return function() {
        return "*" + p + "*";
    }
}

The site allows you to create any number of the closures, specifying the value of p and q arguments. All created instances are saved in closure_list array and are always on display. Watch what happens to those closure instances.

Here's the demo steps:

  1. Optionally modify "p" argument, press "Create" button and watch how a nested function was created (you also can see what it evaluates to). Create more closures with other "p" and "q" values if you want.
  2. Open DevTools and in scripting.js do some "innocent" edits to the inner function. For example, change "*" to "$". Save.
  3. Back on the site, press "Refresh" button and see that the function text has been changed and that its result now is different. This is a trivial live editing.
  4. Optionally in DevTools watch closure_list global variable. It keeps our closure. Open its "function scope" node, and see that it only holds "p" and doesn't keep "q". That is where the problem stems from.
  5. In DevTools do "non-trivial" change to the inner function: add "q" value to return expression.
  6. Back on the site, press "Refresh" button and see that existing function(s) was not changed. Neither their result changed. That's because you commandeered "q" variable in the expression, but there is nowhere "q" actual value could be got from – only "p" value was saved in the function scope, as we observed in step #4.
  7. Optionally enter your signature string in "q" argument field and press "Create". See a new function with a new body text appears. Check that is also evaluates to the something with "q" value. Old instances remain unchanged.
  8. That is how LiveEdit works. If you patch a function to start using a new variable from outside, you cannot have it with function instance that is already around, because it doesn't have the variable value. The variable value is either bound or released at the instantiation moment, no later. All already created function instances will remain unpatched. Only newly created function instances will get a new body text.
  9. What was meant to be a plain function, now gets 2 versions. Since the demo keeps all instances, it's on display how some of them have old text, and some of them have a new text.
  10. Since every function belongs to the script, the script itself must be split into 2 versions. Naturally, you must be able to step through the function and debugger must bring up the corresponding script text. Since there are 2 versions of the function, there must be 2 versions of the script.
  11. LiveEdit V8 engine creates the required script copy. However, DevTools does not currently allow it to UI, which is probably a bug: you are going to fail to step into such function, because it lacks a script. However, the function is seemingly alright in other means, for example you can call it or see its text.

Sorry for a long story. I understand it was complex. I hope this can help us understand how we can try to make LiveEdit more clear for the user – I guess first we should make it clear for ourselves. For example, once I have written it, we could implement a scenario: only "innocent" changes go smoothly. In the complex scenario we can pop up a dialog: «Hey, you are doing a complicated thing. Somewhere in your edits you started to use variable "q" – a thing we were not prepared for. For this fault you will get your script split. Ok with that?»

Peter


Remote debugging updates

  • usb free
  • screencast
    • inspect elem, kbd, mouse, scroll, etc
  • portforward new UI
  • squid proxy setup ( http://goo.gl/QHvdK )
  • use beta!! google play link
    • might soon be in Play search

advantages of no wifi debugging:

  • battery
  • network
  • stayawake

"Not optimized" JavaScript profiler bailout reasons

Edit (sept 2015): This issue is the living documentation for the deopt & bailout reasons provided by Chrome DevTools and the V8 sampling profiler.

image

Should I care?

A deopt warning is important to consider if:

  • You've profiled a slow interaction
  • When viewing a Costly Functions / bottom-up / Heavy report of all operations, sorted by self-time, the function is towards the top
  • The function has significant self-time. Fixing the deopt will reduce the self-time of this particular function.

What is a deopt?

The optimizing compiler makes for very fast execution, but functions are not always optimized, and it depends on a number of indicators. First, there's four types of function optimization state:

  1. Optimized: V8 has identified this function is hot (runs a lot) and has run it through the optimizing compiler so execution is faster.
  2. Unoptimized: The function was not identified by V8 to be worth optimizing.
  3. Deoptimized (bailout): V8 wanted to optimize this function, but before executing it, the optimizing compiler refused to optimize because it uses some unsupported Javascript feature (e.g. try/catch, for of, or with()) or hits certain limitations.
  4. Deoptimized (deopt): V8 wanted to optimize this function, and did successfully send it through the optimizing compiler. However, this already optimized code runs into a situation it did not foresee and cannot handle. (for example: using a negative array key, or a unexpected variable type). V8 then throws away the optimized code, falls back to unoptimized code and tries again later with more information.

These warnings in DevTools will be shown for both 3 and 4.

These deopt affect only that function, and not its children. For example, try/catch is one of the most common warnings. You can address the concern by using a separate function for the body of the try{} block:

These deopt rules change frequency, so always profile before following these rules arbitrarily across your codebase. In try/catch's case, V8's upcoming Turbofan compiler will optimize code that includes a try/catch block. Turbofan is expected to land in Chrome 48.

Related items:

What do each of the reasons mean?

Read the comments below.

Publish the latest stuff

Here's what's queued up to get published:
552e81f...master

It's a LOT.

Remaining:

  • the great image cull #36 (optional)
  • pull commits into remote p4 instance
  • p4 add/remove/change everything that's changed
  • put up a CL
  • @addyosmani and @dr4b review on that CL
  • submit it and publish LIVE

Unfortunately we cannot stage the whole thing as stage fails with files >1mb. What files do we have over that number?

emulation preset galaxy note 3

Hello CHrome Dev Team
I don't know where to address this, so I will do it here

The presets in the emulation tab arent correct for the galaxy note 3. The devicePixelRatio should be 2.5(webview) or 3 and not 2.

Thank you for fixing this. I love the emulation!

keep up the good work!

Show Potential Scroll bottlenecks / Scrolling Perf Issues

This feature is kind of black magic (to me, at least). Let's try to demystify it a bit.

void RenderWidgetCompositor::setShowScrollBottleneckRects(bool show) {
  cc::LayerTreeDebugState debug_state = layer_tree_host_->debug_state();
  debug_state.show_touch_event_handler_rects = show;
  debug_state.show_wheel_event_handler_rects = show;
  debug_state.show_non_fast_scrollable_rects = show;
  layer_tree_host_->SetDebugState(debug_state);
}

https://code.google.com/p/chromium/codesearch#chromium/src/cc/debug/layer_tree_debug_state.cc&sq=package:chromium&type=cs

https://code.google.com/p/chromium/codesearch#chromium/src/content/renderer/gpu/render_widget_compositor.cc&sq=package:chromium&type=cs&q=RenderWidgetCompositor::setShowScrollBottleneckRects

to be continued…

DevTools writeup: the long resume

we need coverage for this feature in the docs. also in a digest makes sense.

image

  1. When paused, resume button has an additional button "Resume with all pauses blocked for 500 ms". This makes all breakpoints disabled for half a second, meant as a quick way of getting the program to its idle state, for scenarios when program's response to user action is being repeatedly debugged. New icon is TBD.
  2. When "refresh" is initiated from DevTools (Ctrl+R in DevTools), all pauses are disabled until the new page load is commenced (or as a plan B, until user presses "pause" button). This reflects the same scenario of giving up the debug iteration and user's waiting for the program to get to its basic state.

The subtle fact is that Browser's refresh still works as usually, i.e. without disabling any pauses. This fact could be used for those, who are actually interested in page unloading process.

also written up here: https://plus.google.com/+BrianArnold/posts/3aHFzbFTW1W?e=-RedirectToSandbox

DevTools Screencasting

@jaredwilli is working on an addition about the new screencasting feature. We'll probably roll that into the remote debugging doc once it's been completed. Jared, could you give us an update on where you are with the current draft? Could we expect to see a PR in tomorrow that we might be able to review? :)

Documentation for the documentation!

Could we get a contributing guide for this repo with instructions aimed at external contributors.

A readme with instructions on how to build locally might be nice, if possible.

Update JavaScript Debugging

edit from paul: this is a massive bug thread. half of it is fixed but many issues raised by pearl are not. We'll keep this one open for now and will help guide a future js debugging tutorial.

https://developer.chrome.com/devtools/docs/javascript-debugging
https://github.com/GoogleChrome/devtools-docs/blob/master/docs/javascript-debugging.html




There are a few different pieces that need to be updated for this doc. - [x] Screenshot refresh of all images (UI is out of date in all) - [ ] Fix demos (a few are no longer working, or external demos have changed) - [x] Update Source Maps section to reflect change in format - [ ] Add features which landed since the doc was first published - [ ] KBD styles

Screenshot update sprint

This issue is to track what pages we would like to update screenshots on for the sprint we'll be doing in early January.

It'll also be super-useful for us to decide on:

  • target image width/height
  • prefer dock-to-right? own window?
  • white background?
  • callouts (arrows etc)

Emulation limitations

Emulation mode doesn't emulate a few things people think it may:

general

  • Features that Chrome supports and the device/browser doesnt
      • e.g., no WebGL in iOS7, no line-height in Opera Mini
  • Features that Chrome doesn't support and the device/browser does
    • e.g. MathML in iOS7
  • browser quirks/bugs
  • GPU behavior
    • like memory constraints, layering
  • behavior of browser chrome (like url bar, etc)
  • network connectivity (3g)

realistic handling of touch emulation

⬆️ now fixed (april 2014) by http://crbug.com/337142

other features that dont obey emulation settings

Any others?

Timeline panel updates

image
image
image
image

  • Details pane / summary.
  • gpu frames on top
  • Capture stacks checkbox (will capture stack traces for all operations it can. pretty much the only part of timeline that has overhead.)
  • GPU activity bars (enabled by setting)
  • filters
  • gpu memory in counters
  • first paint, domcontentloaded, windowload, and console.timeStamp plotted

Comment below with other parts that are new…

Improve the network throttling section for mobile

The mobile emulation section tells developers what tools are available however it doesn't cover what some decent settings to test against would be. I have seen in some performance talks from @igrigorik that there are known ranges for the network latency. For example (if I am reading correctly) the Control Plane row from the table at this point in his Breaking the 1000ms Mobile Barrier talk.

It shows 3G having a range of 200-2500ms of latency and 4G with 50-100ms. So, if I am understanding this correctly then we should probably recommend a test latency of 75 ms for 4G as a good middle-ground. Then for 3G we should probably recommend testing at the worst (200ms) and from there test against a few points in the range given the huge gap between the extremes.

Or should we actually be recommending tests parameters based on the total calculated latency of the networks? Which are 1055-4300ms for 3G and 555-1220 ms for 4G.

Workspaces & LiveEdit

  • workspaces. how do they work
  • WS & Sass
  • LiveEdit is a gateway drug into workspaces, but its also a complement when you're using them
    • its not clear how many people start with which feature
  • include links to Remy's stuff.
  • what "[VM] file (322)" means
  • When changing a file, why it adds * to the end of filename and what that means
  • Explain saving: Ctrl/Cmd + S vs right click and Save/Save as...

Document DevTools extension API workarounds

Common asks from developers (braindump from my STP talk):

  • Communicating between a panel, DevTools page and a bg page. Implied as the documentation says chrome.extension runtime APIs not available. Unfortunately, no alternatives offered.
  • Better hooks for letting a framework augment rendered console objects. Allows you to differentiate between framework specific objects and meta-objects.
  • It's not possible to execute XHRs from a DevTools page/panel. May be worth mentioning a background page could be used as a workaround.
  • When is a script added or executed? Useful for extensions to know.
  • Want to be able to inspect pseudo-elements/tree from an extension.
  • Ability to create context-menus for extension panels more easily.
  • Would like to be able to let a framework name anonymous functions. Ideally with the extension enabled, displayName is used as a property for inferring the function name.
  • Ability to change the context of the DevTools.
  • Difficult to know why an action/function is being blocked rather than silently ignoring.
  • Diagram of how to setup and structure a DevTools extension. Role of a DevTools page (panels, buttons, management) Communicating between different parts (pane, panel, background page)

Allocation profiler - memory heap allocation analysis

watch this:

![image](https://cloud.githubusercontent.com/assets/39191/5909643/562aff8c-a567-11e4-92b6-198a2dd22be9.png) ## Instructions to use heap allocation profiler 1. open devtools profiler 2. do a warm-up action 3. start allocation profiler 4. repeat action a few times 5. if the action has a leak you will see the same number of groups of blue bars in the overview pane 6. stop the profiler 7. select one group of these blue bars in the overview 8. look into the list of objects

The allocation profiler takes heap snapshots periodically throughout the recording (as frequently as every 50 ms!) and one final snapshot at the end of the recording.

image

The bars at the top indicate when new objects are found in the heap. The height of each bar corresponds to the size of the recently allocated objects, and the color of the bars indicate whether or not those objects are still live in the final heap snapshot: blue bars indicate objects that are still live at the end of the timeline, gray bars indicate objects that were allocated during the timeline, but have since been garbage collected.

In the example above, an action was performed 10 times. The sample program caches five objects, so the last five blue bars are expected. But the leftmost blue bar indicates a potential problem. You can then use the sliders in the timeline above to zoom in on that particular snapshot and see the objects that were recently allocated at that point. Clicking on a specific object in the heap will show its retaining tree in the bottom portion of the heap snapshot. Examining the retaining path to the object should give you enough information to understand why the object was not collected, and you can make the necessary code changes to remove the unnecessary reference.

Record heap allocation timeline

image

See allocated memory by function

image

references

CLAs required?

Yo! @paulirish A few of our teams (e.g Dart) require CLAs before external contributions can be landed to their docs.

Possible to get a confirm on whether this will be needed for this repo as it's CC?

Updates needed on the shortcuts page

All of this is in Chrome Canary/Stable on Windows 7.

The table of contents lists "Search Shortcuts" (https://developers.google.com/chrome-developer-tools/docs/shortcuts#search-shortcuts) but this doesn't exist and doesn't link to the anchor.

https://developers.google.com/chrome-developer-tools/docs/shortcuts#all-panels
Backwards/forwards in panel history - the shortcuts are reversed (confirmed in the settings/shortcuts inside the panel itself)
Search by Filename - lists the same shortcut twice for Windows/Linux and Mac. I'm not sure why...?

https://developers.google.com/chrome-developer-tools/docs/shortcuts#elements-panel
Redo Change - "CTRL-SHIFT-Z" doesn't seem to redo change

https://developers.google.com/chrome-developer-tools/docs/shortcuts#styles-sidebar
Edit Rule - should be single click, not double
Insert New Property - should be single click, not double

https://developers.google.com/chrome-developer-tools/docs/shortcuts#console
Clear History - this is named "Clear console" in the right-click menu, which seems inconsistent naming. Also, "Clear console" should be listed in the "right-clicking" section below the "Console" shortcuts.

console / command line API changes

Validating docs through automation

@paulirish @addyosmani I've noticed a few times that there have been very minor errors in the docs, such as spelling or some incorrect HTML for example. How about we rely on automation to validate (at least) the HTML markup? There are a bunch of NPM modules which could assist with this, maybe even having Travis actually run the 'tests' could be nice?

Flamechart update

this is a small addition:

the colors in the flamechart are reused for same functions. this helps you see a common pattern and then spot outliers better.

there is no correlation to colors used in timeline for things.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.