Firebug Guide for Web Designers - Web Debugging Tool

Method 1: Offline and online
Open FireFox -> Tools -> Add-ons .

=>  Add ons Manager browser appear. Then Search type firebug.

List of firebug version listed. Select install and Reload your browser after successful installation.

Right click on browser and select Element by firebug appear last option.

Chrome : Right click -> inspect element-> emulate -> varity of device list


Optional Mobile design testing:
------------------------------------

Open firefox=> menu => tools => web developer => Responsive Design

Customized window appear for testing mobile sized (testing).




Method 2:  Thanks for Ref:
http://sixrevisions.com/tools/firebug-guide-web-designers/

Firebug — an open source web development tool extension for the Mozilla Firefox web browser — is incredibly powerful, with a wide range of super useful and practical features that would benefit any web designer or developer.

In fact, this browser extension (also available in other web browsers with limited functionality) is so useful and popular that it has browser extensions of its own.

This real-time coding tool reduces the guesswork out of debugging web pages, among many other things such web page layout inspection/testing and web performance profiling, to speed up your workflow.

Whether you’re building a web page, adding new CSS for a responsive web design, troubleshooting web layout issues, or inspecting how other websites are built, Firebug is going to be a valuable tool in your arsenal.

Let’s take a closer look at how this indispensable browser extension can help web designers. We’ll only focus on certain Firebug functionalities that are especially helpful for web designers.

Getting Started with Firebug

First, you’ll need to download and install Mozilla Firefox if you don’t already have it.

Then you also need to download and install Firebug.

Once you’ve got the extension installed, you’re ready to start dissecting any website.

You can experiment with how it works just by playing around with it or you can take some time to read the official Firebug documentation (which is a wiki).

Opening the Firebug Panel

There are several ways to open the Firebug panel. When it’s open, it should look like the image below.

Opening Firebug Using a Keyboard Shortcut

Press F12, which is the keyboard shortcut to toggle Firebug on and off (see otherFirebug keyboard shortcuts).

Opening Firebug in the Browser’s Context Menu

On any web page, right-click on the page or a particular HTML element (such as a hyperlink, a text heading, an image, a form button, etc.) and then choose Inspect Element from the context menu that appears.

Firebug Icon

You can also click on the Firebug icon to open the Firebug panel. Depending on your version of Firefox, it will be in the bottom status bar, or in the upper chrome to the right of the search bar.

Tip: Have Firebug in Its Own Window

Once you have Firebug open, feel free to break it out of the browser and into its own window by pressing the Open Firebug in New Window icon. This is perfect for big monitors or for multi-monitor computer set-ups.

Now you’re ready to do some damage. Next, we will talk about some useful Firebug features and techniques.

Inspecting a Web Page’s Layout and Markup

It’s the most common question you’ll ask about a web page you’re developing: "Where’s the flaw?" (or "WTF" for short). The most common use of Firebug is inspection.

Once Firebug is open, you’ll be in the HTML panel by default. This is the panel that will help you inspect and understand the web page’s HTML elements.

There are two panes in the HTML panel. Let’s briefly discuss these panes.

Node View Pane

Firstly, on the left, is the Node View pane displaying the generated source of the page you are currently on.

Node View allows you to edit HTML elements/code on the web page and then see the result on the fly.

When you mouse over the HTML markup in Node View, the browser actually highlights the element on the web page being inspected. This is incredibly helpful functionality – it shows you exactly how the browser is handling your HTML elements and where that particular element is on the actual web page. This can help you visualize margin/padding issues and float problems, for example.

When you click on an HTML element in Node View, it will show the element stacking order just above the pane. This is helpful for any CSS you have to write that needs to be more specific to prevent styling similar elements elsewhere on your site. More often than not, I’m inspecting to see what CSS rules are being inherited.

To help you quickly find HTML elements, try the search feature towards the right of the HTML panel, which will, in Node View, highlight the matched text in gray.

HTML Side Panels

The second pane, on the right, is the Side Panels. These panels give you more information on the highlighted element.

There are four side panels in the HTML panel.

1. Style
2. Computed
3. Layout
4. DOM (which stands for document object model)

The Style side panel shows you what CSS style declarations affects a particular element. It also displays which style sheet (and what line number) the style rule is in, in case you have more than one stylesheet.

The Computed side panel displays CSS properties of the HTML element such as font-size, color, text-align etc. This gives you information on how the web browser renders the element.

The Layout side panel visually shows you the box model of the element you’ve clicked on. If you’re a visual learner like me, it’s really nice to see the padding, border and margin illustrated like this. Double-clicking on the displayed values allows you to make changes and experiment in real-time.

The DOM side panel displays the document object model information of the selected element. It’s especially useful for front-end web developers working withJavaScript/client-side scripting.

Edit HTML on the Fly

There are a hundred different ways to manage your HTML workflow when you have access to files on the server or when you’re working in a local server environment using a web server stack like XAMPP or WampServer. I think most people prefer to work right in their own code editor, so code can be saved as you go whenever they can.

However, for quick in-browser tests and situations where you don’t have access to the HTML files (such as a website you don’t own or when you’re away from your dev computer), Firebug is perfect.

In Node View of the HTML panel, you can click on any HTML element and edit it. Add or remove whatever you like and then see what results your changes make to the web page.

A few common tasks I perform in this way include:

• Adding/removing entire HTML elements (e.g. "What happens to the floats if I remove this div?")
• Adding/removing a class or ID to elements (e.g. "Will the rendering issue get fixed if I remove this CSS class?")
• Substituting longer text on titles and buttons to test line breaks
• Adding temporary inline styles for quick testing using the style HTML property (e.g. "Will this hyperlink look better with style="color:#00aeef" orstyle="color:# 067fad"?")

Firebug doesn’t save any code you write in it; when you click a link or refresh the page, your changes are gone. (And you wouldn’t want it any other way!) So, it’s a good idea to keep a text editor handy for pasting in code you’ve tried or may want to keep.

Editing CSS on the Fly

Editing CSS within Firebug is where the real action is, at least for web designers. As has been mentioned, inspecting an HTML element on the page will reveal its inherited styles in the Node View of the HTML panel. These styles are listed alphabetically, and grouped by selector on Style side panel.

The selectors are presented in the rendered CSS order: the most recent declaration at the top (for example, something at the beginning of the style sheet will be at the bottom of the CSS pane, and inline styles would be shown at the top aselement.style).

If you use multiple style sheets, it does the same thing. For example, I’ll often use Eric Meyer’s CSS reset as the first style sheet on a site, so I’ll often see a very long selector at the bottom of my Style side panel.

Firebug makes it clear which styles are actively affecting your HTML element by crossing out the CSS properties that have been superseded by another CSS property declaration. If there’s a line through it, then it means that another CSS rule has overwritten it by being declared after the former rule, or by being !important.

The great thing about the CSS in the Style side panel is that it’s editable. Want to see how the web page would look if you changed the element’s padding-top property to22px? Click on the property value and change it. You can also change the property itself (e.g. change padding-top to padding-bottom).

You can also disable/hide a CSS property/value pair to see what the page would look like if it didn’t have that rule. This is useful for seeing unneeded CSS lines in the web page, determining if the property declaration is what’s causing rendering issues, etc.

When you’re editing CSS in the Style side panel, the Enter key will jump to the next editable cell – from property to value, and down to the next property.

When you’re at the last property of the selector, hitting Enter will give you a new line, where you can add a new CSS property/value pair.

Now if you want to add CSS to an element that doesn’t have a class or ID (and therefore won’t appear in the Style side panel), you can either add inline styles in Node View, or venture into the CSS panel.

The CSS panel shows you a page-view of the various style sheets you’ll have attached to the site.

In Source Edit mode, you are able to edit values (Similar to the HTML panel’s Style side panel we discussed earlier). In Live Edit mode, you can actually type freely as if you were working on your site’s style sheet in a code editor.

Editing via the CSS panel.

Firebug Quirks and Limitations

Even Firebug has its quirks, but with the insane release schedule Firefox is under lately, who can blame it?

Here are a few issues that cause occasional hiccups when using Firebug for debugging, as well as some limitations you will have when working with it. Let’s just talk about a few of them.

HTML Elements with Hover Properties

It can be hard to troubleshoot elements that have CSS :hover rules or JavaScript hover events, like fly-out drop-down menus because the Node View updates the markup when you mouse out of the element. So one issue is that it gets tricky to study nested elements of the parent element that are hidden until you hover over the parent.

I’ll usually work around this by using the style HTML property to force the element to be visible, which isn’t ideal for a live-test, but gets the job quickly done.

For example, say I want to debug and study the unordered list in the flyout-menu div below. But there’s JavaScript that hides the div when the mouse isn’t on the element.

<div class="flyout-menu">
  <ul>
    <li>Menu item one</li>
    <li>Menu item two</li>
    <li>Menu item three</li>
  </ul>
</div>

I can just add, for example — because it depends on how the div was hidden but basically you want to counteract the JavaScript DOM manipulation — the following inline style to the div.

<div class="flyout-menu" style="display:block;">
  <ul>
    <li>Menu item one</li>
    <li>Menu item two</li>
    <li>Menu item three</li>
  </ul>
</div>

For more solutions to this issue, read this Stack Overflow question and answer thread.

Firebug CSS Panel Bugs Out Sometimes

Occasionally the CSS panel will be unable to provide you with Edit Mode and then it will throw an error. I can’t pinpoint the cause, but if you’re testing various User Agents, it happens a lot more. A browser restart usually fixes it.

No Code Formatting Options

You don’t really have an option to display and format that code you see in Firebug based on your own preferences/formatting guidelines. So, if you were going to copy CSS or HTML directly into your work, for example, what you see is what you get. However, there are many online CSS formatters you can use after (or during) development.

Firefox is Different from Other Web Browsers

Another interesting "problem" is that Firefox is a pretty great browser! So good, in fact, that it can cause issues when it smartly corrects errors in the markup.

For example, consider the following list item element:

<li><a href="home.htm">Home</li>

Someone has forgotten the closing </a> tag. Some browsers may render this properly by respecting this error, and have the link spiral out of control. Firefox, however — and subsequently Firebug because it relies on Firefox’s layout engine — will show you the </a> in the proper place. (This is called the generated source.)

This essentially means that if you’re having an issue in another browser, Firebug may not give a 100% accurate representation of the same code. This also means that what you see (and fix) in Firefox, may still cause trouble in other browsers because of layout-rendering differences and error-treatment disparities between browsers.

So, Firebug won’t completely save you from having to debug in other browsers. However, Firebug is available for some other browsers besides Firefox: It’s available in a Lite version for browsers such as Google Chrome.

Additionally, Google Chrome, Safari, IE and Opera have similar development tools:

• Google Chrome: check out the built-in Chrome Developer Tools
• Apple Safari: see the WebKit Web Inspector
• Internet Explorer: see the Internet Explorer Developer Tools
• Opera: has the Opera Developer Tools

HTML5 web storage API's 3 types. 2 Fame, session storage separate from web storage.

HTML5 Storage Wars - localStorage vs. IndexedDB vs. Web SQL

Currently, there are three competing approaches for saving serious amounts of data (i.e., persistently, and bigger than cookies) locally in your browser:

1. Web Storage
2. Indexed Database API
3. Web SQL Database

These names sure seem similar. But the implementations sure are different. Let's quickly summarize what they do, the PROs and CONs, and what I like best at the moment. Though I'm sure my opinions will age quickly as the technology matures.

All these technologies use the same-origin protection for data access (i.e., javascript can only access data from the url's domain that it was served from), which is fine and not a differentiator so I won't mention that below.

Web Storage

Web Storage, and specifically the localStorage part of it, is a really simple key/value persistence system.

PRO: Really simple API.

PRO: Already available in all major new browsers.

CON: No query language, schemas, really nothing you'd normally call a database. So it wouldn't scale well where you need to impose organization on a larger data set.

CON: They didn't put transactional safety into the standard. I don't think I can sleep at night with an app running that might have race conditions and then have the risk of corrupt data.

Indexed Database API

IndexedDB is basically a simple flat-file database with hierarchical key/value persistence and basic indexing.

PRO: If you're a NoSQL type of person, then this might fit the bill perfectly.

CON: Not yet available in most new browsers.

CON: If you wanted SQL, you're not getting it here. Though in the future, it might be a great building block for implementing a SQL engine for the browser.

Web SQL Database

Web Sql is basically sqlite embedded into the browser. I've used sqlite off-and-on for a few years. At first I was turned off by the name (excuse my superficiality) and by the architecture (just a flat file database). But after digging into it, I found that it's a rock solid platform, and great for production use, as long as you keep in mind its limitations. Itslimitations aren't so much size (I think you can go at least 1 GB without a problem), but inherent in flat file databases (high levels of concurrency) and missing features (stored procs and other higher-end database features).

PRO: Fast and pretty feature-rich sql implementation (besides select/insert/update/delete, you can do joins, inner selects, etc).

CON: Available in Chrome and webkit-based browsers (Safari, etc.) but not Firefox or IE.

CON: The darn W3C Working Group has put a hold on the standard since they say they want at least two independent implementations of the standard, and there's only one so far, since everybody is using sqlite.

I wish the standards group would make a special case for sqlite and approve this standard -- it's in the public domain, so it's available to everybody in the world, no strings attached. Sqlite is a perfect fit for browsers - its limitations are not problems. Only one user is using a browser at a time, so no concurrency issues.  And no one wants high-end database features in a simple no-administration database. I think that's why both Android and iOS use sqlite for storage.

Bottom line

If you're only deploying on mobile platforms, then Web SQL is a no-brainer. Or if you're running on desktops and can require Chrome or Safari as your browser, then Web SQL is also for you. I wouldn't use the other two standards in any heavy-duty app at the moment.

Thanks for Ref:
http://csimms.botonomy.com/2011/05/html5-storage-wars-localstorage-vs-indexeddb-vs-web-sql.html

HTML5 Storage-size LocalStorage 5MB per app per browser.

1. What is HTML5 Storage?
2. Why Use HTML5 Storage?
3. Details You Should Know About HTML5 Storage
4. HTML5 Storage Support in GWT
5. How to Use HTML5 Storage in Your Web Application

Starting with GWT 2.3, the GWT SDK provides support for HTML5 client-side storage, also known as "web storage". Using the GWT library's Storage capability enables your web application to take advantage of these storage features when running in an HTML5-compliant browser.

What is HTML5 Storage?

The HTML5 (web) storage spec is a standardized way of providing larger amounts of client-side storage and of more appropriately "partitioning" session storage and locally persistent storage. The HTML5 spec also provides for storage events to be generated and handled by interested listeners. The full impact of these features provided by HTML5 storage can best be seen by looking at client-side storage in the non-HTML5 world.

Without HTML5, client-side storage for web applications is limited to the tiny storage provided by cookies (4KB per cookie, 20 cookies per domain) unless proprietary storage schemes are used, such as Flash local shared objects or Google Gears. If cookies are used they provide both session and locally persistent storage at the same time, and are accessible by all browser windows and tabs. Domain cookies are sent with every request to that domain, which consumes bandwidth. The "mechanics" of processing cookies are also a bit cumbersome.

In contrast, HTML5 storage provides a much larger initial local storage (5MB per domain), unlimited session storage (limited only by system resources) and successfully partitions local and session storage so that only the data you want to persist is persisted in local storage and data you want to be transient stays transient. Moreover, session storage is only accessible from its originating tab or window; it is not shared between all browser windows and tabs. Accessing session and local storage is simple, consisting in simple reads and writes of key-value strings. Finally, local and session storage are client-side only; they are not sent with requests.

Why Use HTML5 Storage?

With HTML5 local storage, a larger amount of data (initially, 5MB per application per browser) can be persistently cached client-side, which provides an alternative to server downloads. A web application can achieve better performance and provide a better user experience if it uses this local storage. For example, your web application can use local storage to cache data from RPC calls for faster startup times and for a more responsive user interface. Other uses include saving the application state locally for a faster restore when the user re-enters the application, and saving the user's work if there is a network outage, and so forth.

Note: The 5MB maximum applies to local storage only, not to session storage, which is limited only by system memory.

Here is a short list of some of the benefits and uses of local storage:

• Reduce network traffic
• Significantly speed up display times
• Cache data from RPC calls
• Load cached data on startup (faster startup)
• Save temporary state
• Restore state upon app reentry
• Prevent work loss from network disconnects

Note: unlike cookies, items in Storage are not sent along in requests, which helps reduce network traffic.

Details You Should Know About HTML5 Storage

To use HTML5 storage features, you need to know about lifespan (persistence) of local and session storage, about their scope--which windows and tabs can access the storage, and which tabs and windows can listen for storage events.

LocalStorage and SessionStorage

HTML5 Web Storage defines two types of key-value storage types: sessionStorage and localStorage. The primary behavioral difference is how long the values persist and how they are shared. The following table shows the differences between the two types of storage.

Storage Type	Max Size	Persistence	Availability to other Windows/tabs	Data Type Supported
LocalStorage	5MB per app per browser. According to the HTML5 spec, this limit can be increased by the user when needed; however, only a few browsers support this	On disk until deleted by user (delete cache) or by the app	Shared across every window and tab of one browser running same web app	String only, as key-value pairs
SessionStorage	Limited only by system memory	Survives only as long as its originating window or tab	Accessible only within the window or tab that created it	String only, as key-value pairs

How Local Storage Is Shared by the Browser

One LocalStorage per web application, with a max size of 5MB, is available for a given browser and is shared by all windows and tabs of that browser. For example, suppose you have MyWebApp running in a Chrome browser on the client. If you run MyWebApp in multiple tabs and windows, they all share the same LocalStorage data , subject to a max limit of 5MB. If you were to then open that same application in another browser, say FireFox, then the new browser would get its own LocalStorage to share with all its own tabs and windows. This is shown in the following figure:

Local Storage is String Storage

HTML5 local storage saves data in string form as key-value pairs. If the data you wish to save is not string data, you are responsible for conversion to and from string when using LocalStorage. For proxy classes used with the GWT RequestFactory, you can use RequestFactory#getSerializer() to do string serializing. For non-proxy objects, you could use JSON stringify and parse.

Note: Just like cookies, LocalStorage and sessionStorage can be inspected using browser tools such as Developer Tools in Chrome, Web Inspector in Safari and so forth. These tools allow a user to remove storage values and see what values are being recorded by a web site the user is visiting.

LocalStorage is Not Secure Storage

HTML5 local storage saves data unencrypted in string form in the regular browser cache. It is not secure storage. It should not be used for sensitive data, such as social security numbers, credit card numbers, logon credentials, and so forth.

How Storage Events Work

When data is added to, modified, or removed from LocalStorage or SessionStorage, a StorageEvent is fired within the current browser tab or window. That Storage event contains the storage object in which the event occurred, the URL of the document to which this storage applies, and both the old and the new values of the key that was changed. Any listener registered for this event can handle it.

Note: Although the HTML5 spec calls for Storage events to be fired in all tabs of the same browser or all windows of the same browser, few browsers currently implement this.

HTML5 Storage Support in GWT

GWT support for the HTML5 storage feature consists of the following:

• com.google.gwt.storage.client.Storage (required import)
• LocalStorage (local storage)
• SessionStorage (session storage)
• StorageEvent (event generated by session or local storage changes)
• StorageEvent.Handler (interface for storage event handlers)
• StorageMap (exposes the Storage object as a standard Map)

Syntactic details for these can be found in the Storage feature javadoc.

How to Use HTML5 Storage in Your Web Application

You get the storage object by invoking Storage.getLocalStorageIfSupported() or Storage.getSessionStorageIfSupported(), depending on the type of storage you want to access. Because your web app might be accessed from a browser that does not support HTML5, you should always check before accessing any of the HTML5 storage features. If the storage feature is supported, you get the storage object and then write data to it or read data from it, depending on your needs. If you want to delete one key-value pair from the storage, you can do that or you can clear all of the data from the storage object.

1. Check for browser support
2. Get the Storage object for your browser
3. Read data from Storage
4. Write data to Storage
5. Delete data from Storage
6. Handle Storage Events

Checking for Browser Support

GWT provides a simple way to determine whether the browser supports HTML5 storage--a built-in check when you get the storage object. You use Storage.getLocalStorageIfSupported() or Storage.getSessionStorageIfSupported(), depending on which type of storage you want to use. The storage object is returned if the feature is supported, or, if not, null is returned.

  import com.google.gwt.storage.client.Storage;
  private Storage stockStore = null;
  stockStore = Storage.getLocalStorageIfSupported();

Getting the Storage Object

If the browser supports HTML5 storage, the Storage.getLocalStorageIfSupported method creates the storage object if it doesn't exist yet, and returns the object. If the storage object already exists, it simply returns the already-existing object. If the browser doesn't support HTML5 storage, this returns null. The Storage.getSessionStorageIfSupported() method works in the same way.

Getting the storage object and checking for browser suppport of HTML5 storage are done at the same time, so the code snippet for doing this should look familiar:

  import com.google.gwt.storage.client.Storage;
  private Storage stockStore = null;
  stockStore = Storage.getLocalStorageIfSupported();

Reading Data from Storage

Data is stored as key-value string pairs, so you need to use the key to get the data. You either have to know what the key is, or you'll need to iterate through the storage using indexes to get keys. Picking good naming conventions for keys can help, and the use of StorageMap can be useful as well. If the data needs to be converted from string, you are responsible for doing that.

The following snippet shows an iteration through the contents of storage, with each item in storage then being written to a separate row in a FlexTable. For simplicity, this assumes all of storage is used only for that FlexTable.

import com.google.gwt.storage.client.Storage;

private FlexTable stocksFlexTable = new FlexTable();
private Storage stockstore = null;

stockStore = Storage.getLocalStorageIfSupported();
if (stockStore != null){
  for (int i = 0; i < stockStore.getLength(); i++){
    String key = stockStore.key(i);
    stocksFlexTable.setText(i+1, 0, stockStore.getItem(key));
    stocksFlexTable.setWidget(i+1, 2, new Label());
  }
}

Using StorageMap to do a Quick Check for Specific Key or Value

If you want to quickly check whether a specific key or a specific value is present in the storage, you can use the StorageMap object by supplying the storage to the StorageMap constructor, then using its containsValue() or containsKey() methods.

In the following snippet, we use a StorageMap to see if a certain value is already in the storage, and if it is not yet stored, we write the data to storage.

stockStore = Storage.getLocalStorageIfSupported();
if (stockStore != null) {
  stockMap = new StorageMap(stockStore);
  if (stockMap.containsValue(symbol)!= true){
    int numStocks = stockStore.getLength();
    stockStore.setItem("Stock."+numStocks, symbol);
}

Writing Data to Storage

To write data, you supply a key name and the string value you wish to save. You can only write string data, so you need to do any conversions from other data types or from objects. (If the object is a proxy used with the GWT RequestFactory, you can use RequestFactory#getSerializer() to do string serializing. For non-proxy objects, you could use JSON stringify and parse.).

Judicious use of naming conventions can help with processing storage data. For example, in a web app named MyWebApp, key-value data associated with rows in a UI table named Stock could have key names prefixed with MyWebApp.Stock.

In the following snippet, which is part of an Add button click handler, a text value is read from a textbox and saved, with the key name concatenated from a prefix and the current number of items in the storage.

import com.google.gwt.storage.client.Storage;

final String symbol = newSymbolTextBox.getText().toUpperCase().trim();
stockStore = Storage.getLocalStorageIfSupported();
if (stockStore != null) {
  int numStocks = stockStore.getLength();
  stockStore.setItem("Stock."+numStocks, symbol);
}

Deleting Data from Storage

You can delete a single key-value pair of data from the storage or you can delete all the data all at once.

Deleting a Specific Key-Value Pair

If you want to delete specific piece of data and you know the key name, you simply supply the key name to the removeItem method like this:myStorage.removeItem(myKey);

If you don't know the key, or need to process a list of keys, you can iterate through the storage using the key method, like this: myStorage.key(myIndexValue);

Clearing the Entire Storage

To clear the storage used by your web app, invoke the clear() method, like this:myStorage.clear();

The following sample snippet provides an example of one way to integrate this method with a UI, in this case a FlexTable that displays items from the storage. The user clears the UI and the storage by clicking on a Clear All button. In the button-click handler we just use the count of items in the storage to iterate through and remove rows from the UI, and when that is done, we delete all the storage data. (To keep things simple, we used the storage only for populating the FlexTable.)

import com.google.gwt.storage.client.Storage;
import com.google.gwt.event.dom.client.ClickEvent;
import com.google.gwt.event.dom.client.ClickHandler;
import com.google.gwt.user.client.ui.Button;
import com.google.gwt.user.client.ui.FlexTable;
import com.google.gwt.user.client.ui.Widget;

// Listen for mouse events on the Clear all button.
clearAllButton.addClickHandler(new ClickHandler() {
  public void onClick(ClickEvent event) {
  // note that in general, events can have sources that are not Widgets.
  Widget sender = (Widget) event.getSource();
  //If HTML5 storage is supported, clear all rows from the FlexTable UI,
  //then clear storage
  if (sender == clearAllButton) {
    stockStore = Storage.getLocalStorageIfSupported();
    if (stockStore !=null) {
      for (int ix =0; ix < stockStore.getLength(); ix++) {
        stocksFlexTable.removeRow(1);
      }

      stockStore.clear();}
    }
  } // if sender is the clear all button
});

Handling Storage Events

You can register storage event handlers with a storage object, and these are invoked for the current window or tab when data is written to or deleted from the storage. Although the HTML5 spec states that storage events fire in all windows and tabs of the browser, this should not be assumed because few browsers implement this. Notice that if the storage is cleared, the event does not contain any information about the deleted key-value pairs.

The storage event handlers get a storage event object that contains various useful information, such as the old value and the new value, in the case of an update to an existing key-value pair. The following can be obtained from the StorageEvent object:

Method	Description
getKey	Returns the key being changed.
getNewValue	Returns the value of the key after the change, or null if not changed or if it is the result of a Storage.clear() operation.
getOldValue	Returns the value of the key before the change, or null if not changed or if it is the result of a Storage.clear() operation.
getStorageArea	Returns the SessionStorage or LocalStorage object where the event occurred.
getURL	The address of the document in which the change occurred.

The following snippet shows a sample event handler registered with a storage, where the changes from the incoming events are displayed in a UI label.

import com.google.gwt.storage.client.Storage;
import com.google.gwt.storage.client.StorageEvent;
private Storage stockstore = null;
stockStore = Storage.getLocalStorageIfSupported();
if (stockStore != null) {
  stockStore.addStorageEventHandler(new StorageEvent.Handler() {
  public void onStorageChange(StorageEvent event) {
    lastStockLabel.setText("Last Update: "+event.getNewValue() +": " +event.getOldValue() +": " +event.getUrl());
  }
});