From 037a4118c4324d39fdef8bd23f9dd21b02f50946 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Thu, 15 Jul 2021 13:01:50 -0400 Subject: delete pages that were never translated from en-US (pl, part 1) (#1549) --- files/pl/tools/browser_toolbox/index.html | 41 ----- files/pl/tools/performance/flame_chart/index.html | 104 ----------- files/pl/tools/storage_inspector/index.html | 207 ---------------------- files/pl/tools/tools_toolbox/index.html | 114 ------------ files/pl/tools/view_source/index.html | 83 --------- 5 files changed, 549 deletions(-) delete mode 100644 files/pl/tools/browser_toolbox/index.html delete mode 100644 files/pl/tools/performance/flame_chart/index.html delete mode 100644 files/pl/tools/storage_inspector/index.html delete mode 100644 files/pl/tools/tools_toolbox/index.html delete mode 100644 files/pl/tools/view_source/index.html (limited to 'files/pl/tools') diff --git a/files/pl/tools/browser_toolbox/index.html b/files/pl/tools/browser_toolbox/index.html deleted file mode 100644 index 6fad126ff6..0000000000 --- a/files/pl/tools/browser_toolbox/index.html +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: Browser Toolbox -slug: Tools/Browser_Toolbox -translation_of: Tools/Browser_Toolbox -original_slug: Narzędzia/Browser_Toolbox ---- -

The Browser Toolbox enables you to debug add-ons and the browser's own JavaScript code rather than just web pages like the normal Toolbox.  The Browser Toolbox's context is the whole browser rather than just single page on a single tab.

- -

Note:  If you want to debug a specific add-on that is restartless or SDK-based then try the Add-on Debugger.  Use the Browser Toolbox for add-ons that are neither.

- -

Enabling the Browser Toolbox 

- -
-

The Browser Toolbox is not enabled by default.  To enable it you need to check the settings "Enable chrome and addon debugging" and "Enable remote debugging".

- -

To do this, open the Developer Tools Toolbox's Settings, go to the section "Advanced Settings", and check the settings "Enable chrome and addon debugging" and "Enable remote debugging".

-
- -

Opening the Browser Toolbox

- -

Open the Browser Toolbox through the menu button new fx menu and the menu items "Developer" then "Browser Toolbox". 

- -

Click the menu item and you'll be presented with a dialog like this (this can be removed by setting the devtools.debugger.prompt-connection property to false):

- -

Click OK, and the Browser Toolbox will open in its own window:

- -

You'll see, and be able to debug, all the JavaScript files loaded by the browser itself and by any add-ons that are running. Altogether you will have access to the following developer tools:

- - - -

Debugging chrome: and about: pages

- -

From Firefox 37 onwards, you can debug chrome: and about: pages using the normal Debugger, just as if they were ordinary content pages.

diff --git a/files/pl/tools/performance/flame_chart/index.html b/files/pl/tools/performance/flame_chart/index.html deleted file mode 100644 index 60b17d4011..0000000000 --- a/files/pl/tools/performance/flame_chart/index.html +++ /dev/null @@ -1,104 +0,0 @@ ---- -title: Flame Chart -slug: Tools/Performance/Flame_Chart -translation_of: Tools/Performance/Flame_Chart -original_slug: Narzędzia/Performance/Flame_Chart ---- -
-

The Flame Chart shows you the state of the JavaScript stack for your code at every millisecond during the performance profile.

- -

This gives you a way to know exactly which function was executing at any point during the recording, how long it ran for, and where it was called from.

-
- -

The Call Tree and the Flame Chart are both used to analyze your site's JavaScript, and they both use the same data: a sample of the JavaScript engine's stack, taken periodically during the recording.

- -

But while the Call Tree organizes this data to show you where your program is spending most time in aggregate across the recording, the Flame Chart uses it to show you when in the recording particular functions are executing. Essentially it shows you the state of the call stack at any given point during the recording.

- -

Here's a screenshot showing the Flame Chart for a section of a profile:

- -

- -

First of all, you'll see that, in the recording overview pane, we've selected a small slice of the recording to view in the Flame Chart. The Flame Chart displays a lot of data, so to get readable results, it's usually necessary to zoom in.

- -

In the Flame Chart view itself, along the X-axis is time. The screenshot above covers the period from 1435ms to a little past 1465ms. Along the Y-axis are the functions on the call stack at that point in time, with the top-level at the top, and the leaf function at the bottom. Functions are color-coded to make them easier to distinguish.

- -

This gives you a way to know exactly which function was executing at any point during the recording, how long it ran for, and where it was called from.

- -

Zooming and panning

- -

To work effectively with the Flame Chart, you'll need to be able to navigate it. There are two main controls you can use to navigate the Flame Chart:

- - - - - - - - - - - - -
Zoom: increase/decrease the selected portion of the complete profile that's displayed in the Flame Chart -

1) Mouse wheel up/down in the Flame Chart.

- -

2) Trackpad 2 fingers up/down in the Flame Chart.

-
Pan: move the selected portion of the complete profile left and right -

1) Click and drag the selected portion in the recording overview pane.

- -

2) Click and drag anywhere in the Flame Chart.

-
- -

{{EmbedYouTube("BzfkBRFucp8")}}

- -

An example

- -

To see how the Flame Chart can reveal the behavior of your program, we'll look at a simple example. We'll use the same example as in the Call Tree page: a program that compares three different sorting algorithms. There's a separate page that gives an overview of this program's structure.

- -

We'll use the same profile file as that used in the Call Tree page. In the call tree page, we figured out that the program call graph in that profile, and the associated sample count, looked like this:

- -
sortAll()                         //    8
-
-    -> sort()                     //   37
-
-        -> bubbleSort()           // 1345
-
-            -> swap()             //  252
-
-        -> selectionSort()        //  190
-
-            -> swap()             //    1
-
-        -> quickSort()            //  103
-
-            -> partition()        //   12
- -

First, we'll just select the whole section in which the program was active:

- -

- -

At the top, colored purple, is the sortAll() call, running throughout the program from start to finish. Underneath that, colored olive-green, are the calls it's making to sort(). Underneath that, like the teeth of a comb, are all the calls being made to each sorting algorithm.

- -

Let's zoom in:

- -

- -

This slice is about 140 ms long, and shows us more details of the functions being called by sort(). The sort() code is just this:

- -
function sort(unsorted) {
-  console.log(bubbleSort(unsorted));
-  console.log(selectionSort(unsorted));
-  console.log(quickSort(unsorted));
-}
- -

The markers labeled "bubb..." and colored olive-green are presumably bubbleSort(). The ones colored plain green are presumably the other sort functions. Even at a glance, we can see that the bubble sort blocks are much wider (of a longer duration) than the others.

- -

We can also see some functions being called from bubbleSort(), colored purple.

- -

Let's zoom in one more time:

- -

- -

This slice is about 20ms long. We can see that the purple markers underneath bubbleSort() are the calls to swap(). If you counted them all, the Call Tree view tells us that you'd see 253 of them. All the ones in this zoom are underneath bubbleSort(), but according to the Call Tree view, the profile does contain one under selectionSort().

- -

We can also see that two of the green markers are for selectionSort() and quickSort(), but we're also seeing calls to platform (Gecko) code in between our calls to the sorting functions. It seems very likely that this is from the console.log() calls in sort().

diff --git a/files/pl/tools/storage_inspector/index.html b/files/pl/tools/storage_inspector/index.html deleted file mode 100644 index 4919111886..0000000000 --- a/files/pl/tools/storage_inspector/index.html +++ /dev/null @@ -1,207 +0,0 @@ ---- -title: Storage Inspector -slug: Tools/Storage_Inspector -translation_of: Tools/Storage_Inspector -original_slug: Narzędzia/Storage_Inspector ---- -
{{ToolsSidebar}}
- -

The Storage Inspector enables you to inspect various types of storage that a web page can use. Currently it can be used to inspect the following storage types:

- - - -

For the time being, the Storage Inspector only gives you a read-only view of storage. But we're working to let you edit storage contents in future releases.

- -

Opening the Storage Inspector

- -

You can open the Storage Inspector by selecting "Storage Inspector" from the Web Developer submenu in the Firefox Menu Panel (or Tools menu if you display the menu bar or are on macOS), or by pressing its Shift + F9 keyboard shortcut.

- -

The Toolbox will appear at the bottom of the browser window, with the Storage Inspector activated. It's just called "Storage" in the Developer Toolbox.

- -

- -

Storage Inspector User Interface

- -

The Storage Inspector UI is split into three main components:

- - - -

- -

Storage tree

- -

The storage tree lists all the storage types that the Storage Inspector can inspect:

- -

- -

Under each type, objects are organized by origin. For cookies, the protocol does not differentiate the origin. For Indexed DB or local storage an origin is a combination of protocol + hostname. For example, "http://mozilla.org" and "https://mozilla.org" are two different origins so local storage items cannot be shared between them.

- -

Under "Cache Storage", objects are organized by origin and then by the name of the cache:

- -

- -

IndexedDB objects are organized by origin, then by database name, then by object store name:

- -

- -

With the Cookies, Local Storage, and Session Storage types, there's only one level in the hierarchy, so stored items are listed directly under each origin:

- -

- -

You can click on each item in the tree to expand or collapse its children. The tree is live, so if a new origin gets added (by adding an iframe, for example), it will be added to each storage type automatically.

- -

Clicking on a tree item will display detailed information about that item in the Table Widget on the right. For example, clicking on an origin which is a child of the Cookies storage type will show all the cookies belonging to that domain.

- -

Table Widget

- -

The table widget displays a list of all the items corresponding to the selected tree item (be it an origin, or database) are listed. Depending on the storage type and tree item, the number of columns in the table might differ.

- -

All the columns in a Table Widget are resizable. You can hide and show columns by context-clicking on the table header and selecting the columns you want to see:

- -

- - - -

There's a search box at the top of the Table Widget:

- -

- -

This filters the table to show only items which match the search term. Items match the search term if any of their fields (including fields whose columns you have hidden) contain the search term.

- -

You can use Ctrl + F (Cmd + F on a Mac) to focus the search box.

- -

Add and refresh storage

- -

You'll also have buttons available to add a new storage entry or refresh the view of the currently viewed storage type where applicable (you can't add new entries to IndexedDB or Cache):

- -

- - - -

When you select any row in the Storage table widget, the sidebar is shown with details about that row. If a cookie is selected, it will list all the details about that cookie.

- -

The sidebar can parse the value of the cookie or local storage item or an IndexedDB item and convert it into a meaningful object instead of just a string. For example:

- - - -

The shown values can also be filtered using the search box at the top of the sidebar.

- -

Cache Storage

- -

Under the Cache Storage type you can see the contents of any DOM caches created using the Cache API. If you select a cache, you'll see a list of the resources it contains. For each resource, you'll see:

- - - -

- -

Cookies

- -

When you select an origin inside the Cookies storage type from the storage tree, all the cookies present for that origin will be listed in the table widget. The cookies table has the following columns:

- - - -
-

Note: Some of the columns are not shown by default — to change the column display, right-click on the existing table headings and use the resulting context menu to show/hide the columns.

-
- -

You can edit cookies by double-clicking inside cells in the Table Widget and editing the values they contain, and add new cookies by clicking the "Plus" (+) button and then editing the resulting new row to the value you want.

- -

Context menu

- -

The context menu for each cookie includes the following commands:

- - - -

- -

Local storage / Session storage

- -

When an origin corresponding to local storage or session storage is selected, the table will list the name and value of all the items corresponding to local storage or session storage.

- -

You can edit local and session storage items by double-clicking inside cells in the Table Widget and editing the values they contain:

- -

{{EmbedYouTube("UKLgBBUi11c")}}

- -

You can delete local storage and session storage entries using the context menu:

- -

- -

In Firefox 68 and later, you can also delete local and session storage entries by selecting the item and pressing the backspace key.

- -

Finally, you can add new storage items by clicking the "Plus" (+) button and then editing the resulting new row to the value you want.

- -

IndexedDB

- -

When you select an origin inside the Indexed DB storage type in the storage tree, the table lists the details of all the databases present for that origin.

- -
-

Note: The data shown in an IndexedDB database is a snapshot of the data as it was when you opened the Storage Inspector tool.

-
- -

Databases have the following details:

- - - -

When an IndexedDB database is selected in the storage tree, details about all the object stores are listed in the table. Any object store has the following details:

- - - -

- -

When an object store is selected in the storage tree, all the items in that object store are listed in the table. All items have a key and a value associated with them.

- -

You can delete an IndexedDB database using the context menu in the Storage tree view:

- -

- -

If the database cannot be deleted (most commonly because there are still active connections to the database), a warning message will be displayed in the Storage Inspector:

- -

You can use the context menu in the table widget to delete all items in an object store, or a particular item:

- -

diff --git a/files/pl/tools/tools_toolbox/index.html b/files/pl/tools/tools_toolbox/index.html deleted file mode 100644 index 8d88d8469f..0000000000 --- a/files/pl/tools/tools_toolbox/index.html +++ /dev/null @@ -1,114 +0,0 @@ ---- -title: Toolbox -slug: Tools/Tools_Toolbox -translation_of: Tools/Tools_Toolbox -original_slug: Narzędzia/Tools_Toolbox ---- -

The Toolbox provides a single home for most of the developer tools that are built into Firefox. You can open it by selecting "Toggle Tools" from the Web Developer menu (under "Tools" on OS X and Linux, or "Firefox" on Windows), or by activating any tool hosted in it (for example, the JavaScript Debugger or the Page Inspector). Alternatively you can press Ctrl + Shift + I on Windows and Linux, or Cmd + Opt + I on OS X.

-

By default, the window appears docked to the bottom side of the Firefox window, but you can detach it if you like. This is what it looks like when it's docked:

-

The window itself is split into two parts: a toolbar along the top, and a main pane underneath:

-

-

Toolbar

-

The toolbar contains controls to activate a particular tool, to dock/float the window, and to close the window.

-

-

Node picker

-

On the far left there's a button to activate the node picker. This lets you select a page element for inspection. See "Selecting elements".

-

Toolbox-hosted tools

-

Then there is an array of labeled buttons which enables you to switch between the different tools hosted by the Toolbox. The array may include the following tools:

- -

Note that not all the hosted tools are always listed here: only the tools actually available in this context are shown (for example, not all tools support remote debugging yet, so if the debugging target is not the Firefox instance that launched the window, not all the hosted tools will be shown).

-

Extra tools

-

Next there's an array of buttons that can be added or removed in the developer tool settings. By default this array includes:

- -

The following tools are not included in the toolbar by default, but you can add them in the settings:

- -

Toolbox controls

-

Finally there's a row of buttons to:

- -

Settings

-

Clicking the "Settings" button () gives you access to settings for the Toolbox itself and for the tools it hosts:

-

-

Default Firefox Developer Tools

-

This group of checkboxes determines which tools are enabled in the toolbox. New tools are often included in Firefox but not enabled by default.

-

Available Toolbox Buttons

-

This group of checkboxes determines which "standalone tools" get buttons in the toolbar. This defaults to the node picker, the split console, and responsive design mode.

-

Firefox 32 adds a button to take a screenshot of the complete web page, which is unchecked by default.

-

Choose DevTools theme

-

This enables you to switch between a light and a dark theme:

-

-

Common preferences

-

Settings that apply to more than one tool. There's just one of these:

- -

Inspector

- -

Web Console

- -

Style Editor

- -

JavaScript Profiler

- -

Editor Preferences

-

Preferences for the CodeMirror source editor, which is included in Firefox and used by several developer tools, including Scratchpad and the Style Editor.

- -

Advanced settings

- -

Main Pane

-

The content of the main pane in the window is entirely controlled by, and specific to, the hosted tool currently selected.

diff --git a/files/pl/tools/view_source/index.html b/files/pl/tools/view_source/index.html deleted file mode 100644 index 206d54d7da..0000000000 --- a/files/pl/tools/view_source/index.html +++ /dev/null @@ -1,83 +0,0 @@ ---- -title: View Source -slug: Tools/View_source -translation_of: Tools/View_source -original_slug: Narzędzia/View_source ---- -
{{ToolsSidebar}}
- -

View Source lets you look at the HTML or XML source for the page you're viewing. To activate View Source:

- - - -

The command opens a new tab with the source for the current page.

- -

View Source features

- -

View Source has three additional features, which can be accessed from the context menu in the View Source tab:

- -

- -
-
Go to Line
-
Scrolls to the specified line. If the number is higher than the lines in a file, you receive an error message.
-
Wrap Long Lines (toggle)
-
Wraps long lines to the width of the page.
-
Syntax Highlighting (toggle)
-
Applies syntax highlighting to the code.When syntax highlighting is on, View Source also highlights parsing errors in red. Hovering your mouse over errors displays a tooltip explaining the error.
-
- -

- -

This feature is useful when you're looking for HTML errors.

- -

To access Go to Line from the keyboard, press Control + Option + L on macOS, or Alt + Shift + L on Windows or Linux.

- - - -

It is possible to link to a particular line, by adding the #lineNNN anchor to the url the browser will jump to the NNN line.

- -

For example view-source:https://www.mozilla.org/#line100

- -

View Selection Source

- -

If you select part of a web page and conext-click, you'll see a context menu item labeled "View Selection Source", that behaves just like "View Page Source", except you only see the source for the selection.

- -

View MathML Source

- -

If you context-click while the mouse is over some MathML, you'll see a context menu item labeled "View MathML Source": click it to see the MathML source.

- -

Limitations of View Source

- -

There are limitations to what View Source does for you that you need to be aware of.

- -

Error reporter ≠ validator

- -

View Source only reports parsing errors, not HTML validity errors. For example, putting a {{ HTMLElement("div") }} element as a child of a {{ HTMLElement("ul") }} element isn't a parse error, but it is not valid HTML. Therefore, this error will not be flagged in View Source. If you want to check that HTML is valid, you should use an HTML validator, such as the one offered by W3C.

- -

Not all parse errors are reported

- -

Even though all the reported errors are parse errors according to the HTML specification, not all parse errors are reported by View Source. Among the errors that don't get reported:

- - - -

XML syntax highlighting

- -

View Source uses the HTML tokenizer when highlighting XML source. While the tokenizer has support for processing instructions when highlighting XML source, that's the only XML-specific capability provided. Because of this, doctypes that have an internal subset are not highlighted correctly, and entity references to custom entities are also not highlighted correctly.

- -

This mishighlighting can be seen by viewing the source of Firefox chrome files (such as XUL documents). However, this shouldn't be a problem in practice when viewing typical XML files.

- -

See also

- - -- cgit v1.2.3-54-g00ecf