Viewed feeds of : Tools to inspect and debug web pages from your browser


      view feed content IETester / Languages (Companion.JS)    [1 views, last view 4 d and 8 h ago]

The language files for IETester can be found on the subfolder "Languages" in the IETester installation file, by default "C:\Program Files\Core Services\IETester". Languages included in the version 0.2.2 :

Here are translation files that are not yet integrated into the installer. You can download them directly and add them to the "Languages" subfolder to have this new language choice :

To create a new translation, get one the existing file (your preferred langage), rename it by using one of the following names and translate the strings :

When it is done, send the file to contact@debugbar.com so it can be added.



View original post | Add to del.icio.us| Updated 33 d and 22 h ago | Share

      view feed content Tor Arne Vestbø is a WebKit Reviewer (WebKit Open Source project)    [2 views, last view 4 d and 16 h ago]

Tor Arne Vestbø is now a qualified WebKit Reviewer. Tor Arne has done a huge amount of work on the Qt port of WebKit, including advanced work such as a Phonon port of the media back end for the <video> element. He’s also helped to enhance our cross-platform abstraction layer. Please join me in congratulating Tor Arne on his reviewer status and thanking him for all of his contributions to WebKit.


[Uncategorized ]
View original post | Add to del.icio.us| Updated 39 d ago | Share

      view feed content Optimizing Page Loading in the Web Browser (WebKit Open Source project)    [3 views, last view 8 d and 0 h ago]

It is well understood that page loading speed in a web browser is limited by the available connection bandwidth. However, it turns out bandwidth is not the only limiting factor and in many cases it is not even the most important one.

The graph above shows the time it took to fully load the Wall Street Journal front page (chosen for its complexity which well represents many modern web sites) with a recent WebKit. Browser caches were cleared before each page load. Mac OS X dummynet facility was used to simulate various network conditions by introducing packet latency and capping the available bandwidth. Since the testing was done against a live web site the actual connection latency is a factor as well (ping time to wsj.com was ~75ms).

From the figure it is clear that while available bandwidth is a significant factor, so is the connection latency. Introducing just 50ms of additional latency doubled the page loading time in high bandwidth case (from ~3200ms to ~6300ms).

Latency is a significant real world problem. Wireless networking technologies often have inherently high latencies. Packet loss and retransmits due to interference makes the situation worse. Geographical distance introduces latency. Just the roundtrip delay between US East and West Coast is somewhere around 70ms. Loaded web servers may not respond immediately.

Why does latency have such a huge impact on page loading speed? After all, to load a page completely a web browser just needs to fetch the page source and all the associated resources. The browser makes multiple connections to servers and tries to load as many resources in parallel as possible. Why would it matter much if it takes slightly longer to start loading an individual resource? Other resources should be loading during that time and the available bandwidth should still get fully utilized.

It turns out that figuring out “all the associated resources” is the hard part of the problem. The browser does not know what resources it should load until it has completely parsed the document. When the browser first receives the HTML text of the document it feeds it to the parser. The parser builds a DOM tree out of the document. When the browser sees an element like <img src> that references an external resource it requests that resources from the network.

Problems start when a document contains references to external scripts, <script src>. Any script can call document.write(). Parsing can’t proceed further before the script is fully loaded and executed and any document.write() output has been inserted into the document text. Since parsing is not proceeding while the script is being loaded no further requests for other resources are made either. This quickly leads to a situation where the script is the only resource loading and connection parallelism does not get exploited at all. A series of script tags essentially loads serially, hugely amplifying effect of the latency.

The situation is made worse by scripts that load additional resources. Since those resources are not known before the script is executed it is critical to load scripts as quickly as possible. The worst case is a script that load more scripts (by using document.write() to write <script> tags), a common pattern in Javascript frameworks and ad scripts.

The latest WebKit nightlies contain some new optimizations to reduce the impact of the network latency. When script loading halts the main parser, we start up a side parser that goes through the rest of the HTML source to find more resources to load. We also prioritize resources so that scripts and stylesheets are loaded before images. The overall effect is that we are now able to load more resources in parallel with scripts, including other scripts.

You can see from the graphs above that these optimizations significantly reduce the impact of network latency and generally improve page loading speed.


[Uncategorized ]
View original post | Add to del.icio.us| Updated 8 months ago | Share

      view feed content Reporting WebKit Security Bugs (WebKit Open Source project)    [1 views, last view 11 d and 21 h ago]

Security is a top priority for the WebKit project. As contributors to the project have grown, it has become apparent that we need a process for safely reporting security vulnerabilities to the WebKit project in addition to the process for reporting vulnerabilities to Apple. Today, we are announcing a new mailing list for this purpose, security [at] webkit.org. In addition, you can now safely report vulnerabilities over https to our bug tracker, https://bugs.webkit.org, by placing the bug in the Security component. The people privy to the mailing list and the Security component are members of the Security group. It currently includes vendors shipping products that include WebKit, active port owners and trusted security experts. If you are shipping a product that includes WebKit and would like to be notified of security issues, please email security [at] webkit.org.


[Uncategorized ]
View original post | Add to del.icio.us| Updated 6 months ago | Share

      view feed content CodePlex Daily Summary for Saturday, July 12, 2008 (Web Development Helper )    [2 views, last view 12 d and 1 h ago]
CodePlex Daily Summary for Saturday, July 12, 2008Most Popular Projects

Most Active Projects

New Releases

New Projects



View original post | Add to del.icio.us| Updated 4 months ago | Share


      view feed content Safari Hits 6.25% Market Share (WebKit Open Source project)    [2 views, last view 13 d and 7 h ago]

The latest browser market share data is in, and Safari has hit 6.25%, breaking 6% for the first time. Last month’s share was 5.81%, so this is a significant increase. It was only nine months ago that Safari broke 5%. Safari market share has now almost tripled from 2.14% in June 2005, when the WebKit Open Source project launched.

This growth, combined with recent WebKit adoption in projects such as the Iris Browser, Qt 4.4, Android, Adobe AIR, Epiphany, KDE Plasma, iCab and more, is breathtaking and shows huge positive momentum for the WebKit project. Thanks and congratulations to everyone who has contributed to the project.


[Uncategorized ]
View original post | Add to del.icio.us| Updated 6 months ago | Share

      view feed content CodePlex Daily Summary for Thursday, August 14, 2008 (Web Development Helper )    [2 views, last view 15 d and 4 h ago]
CodePlex Daily Summary for Thursday, August 14, 2008Most Popular Projects

Most Active Projects

New Releases

New Projects



View original post | Add to del.icio.us| Updated 3 months ago | Share


      view feed content IETester / HomePage (Companion.JS)    [4 views, last view 18 d and 15 h ago]

IETester is a free WebBrowser that allows you to have the rendering and javascript engines of IE 6 and IE5.5 on Vista and XP, as well as the installed IE in the same process.

This is an alpha release, so feel free to post comments/bugs on the IETester forum or contact me directly.
Minimum requirement : Windows Vista or Windows XP with IE7

Download IETester

Known problems and limitations :

View original post | Add to del.icio.us| Updated 9 months ago | Share

      view feed content Third Annual WebKit Open Source Party (WebKit Open Source project)    [4 views, last view 22 d and 15 h ago]

It’s that time of year again! If you are a Mac OS X developer, a browser hacker, a web developer, or just someone with an interest in cool technology, then come have a drink and some snacks, and meet WebKit contributors from Apple and around the world. This event is open to anyone who is interested, free of charge.

Don’t miss out on the nerd party of the century!!!!

Details

Place: Thirsty Bear Restaurant & Brewery (map)
Date: Tuesday, June 10th
Time: 7:30 PM
upcoming.org


[Uncategorized ]
View original post | Add to del.icio.us| Updated 6 months ago | Share

      view feed content CSS Reflections (WebKit Open Source project)    [6 views, last view 23 d and 5 h ago]

WebKit now supports reflections in CSS. Continuing the trend of using adorable baby photos to make features appear more impressive, let me introduce Kate again.

A reflection is a replica of the original object with its own specific transform and mask. The box-reflect property can be used to specify the specialized transform and mask that should be used for the replica.

-webkit-box-reflect: <direction> <offset> <mask-box-image>

<direction> can be one of above, below, left or right.
<offset> is a length or percentage that specifies the distance of the reflection from the edge of the original border box (using the direction specified). It can be omitted, in which case it defaults to 0.
<mask-box-image> is a mask-box-image that can be used to overlay the reflection. If omitted, the reflection has no mask.

Reflections will update automatically as the source changes. If you hover over links, you’ll see the hover effect happen in the reflection. If you reflect the <video> element, you will see the video playing in the reflection.

Giving an element a reflection has the effect of creating a stacking context (so it joins opacity, masks and transforms). The reflection is non-interactive, so from the point of view of hit testing, it’s like it isn’t there. The reflection will have no effect on layout (other than being part of a container’s overflow), and can be thought of as similar to box-shadow in this respect.

The example above uses a gradient mask. Here is the sample code:

<img src=”bubbles.jpg” style=”border:5px solid white;-webkit-box-reflect:below 5px -webkit-gradient(linear, left top, left bottom, from(transparent), color-stop(0.5, transparent), to(white));”>


[Uncategorized ]
View original post | Add to del.icio.us| Updated 7 months ago | Share

      view feed content CodePlex Daily Summary for Saturday, July 05, 2008 (Web Development Helper )    [1 views, last view 27 d and 0 h ago]
CodePlex Daily Summary for Saturday, July 05, 2008Most Popular Projects

Most Active Projects

New Releases

New Projects



View original post | Add to del.icio.us| Updated 4 months ago | Share


      view feed content CSS Masks (WebKit Open Source project)    [2 views, last view 29 d and 1 h ago]

WebKit now supports alpha masks in CSS. Masks allow you to overlay the content of a box with a pattern that can be used to knock out portions of that box in the final display. In other words, you can clip to complex shapes based off the alpha of an image.

Here is a snapshot of the Speed Racer movie trailer clipped to the Safari compass icon. This is in fact a mask applied to the <video> element.

We have introduced new properties to provide Web designers with a lot of control over these masks and how they are applied. The new properties are analogous to the background and border-image properties that already exist.

-webkit-mask (background)
-webkit-mask-attachment (background-attachment)
-webkit-mask-clip (background-clip)
-webkit-mask-origin (background-origin)
-webkit-mask-image (background-image)
-webkit-mask-repeat (background-repeat)
-webkit-mask-composite (background-composite)
-webkit-mask-box-image (border-image)

Use of a mask results in a stacking context being created (similar to how opacity and transforms work). The mask will therefore overlay the child and all of its descendants, and at a minimum will knock out everything outside the border box of the object.

From a Web designer’s perspective, think of the mask as being constructed the way the backgrounds and border-image of a box are constructed. Multiple backgrounds are stacking on top of one another (possibly overlapping) with their own tiling and clipping rules. A border-image can then potentially be stretched or tiled over the backgrounds.

The final resultant image built from putting all of the mask images together, tiling them, stretching them, etc., then becomes the mask used to clip the content. Alpha values of 0 in the mask mean that nothing should be drawn. Alpha values of 1 mean the content should display normally. Anything in between ends up partially transparent.

One key difference between mask-box-image and its border-image counterpart is that it doesn’t attempt to fit itself to border widths. It will just render the corners unscaled and tile/stretch itself into the border box without regard for the border itself. This lets you easily use nine-piece-image effects as masks on elements without borders (often image or video elements).

Here are two sample images. The source image that we want to mask and then the image that we will use as the mask.

We can place a mask on the image element simply by doing this:

<img src=”kate.png” style=”-webkit-mask-box-image: url(mask.png) 75 stretch;”>

The result looks like this:

CSS gradients can be used as the mask image source as well. In the following example a linear gradient is used to achieve a fade effect. For example:

<img src=”kate.png” style=”-webkit-mask-image: -webkit-gradient(linear, left top, left bottom, from(rgba(0,0,0,1), to(rgba(0,0,0,0))”>

Masks respect the border-radius curves of an object. We can add a border-radius to the previous example, and have both the gradient fade effect with rounded corners.

<img src=”kate.png” style=”-webkit-border-radius: 10px; -webkit-mask-image: -webkit-gradient(linear, left top, left bottom, from(rgba(0,0,0,1), to(rgba(0,0,0,0))”>

SVG images can be used as masks. For example, a partially transparent circle:

can be applied as a mask like so:

<img src=”kate.png” style=”-webkit-mask-image: url(circle.svg)”>

The end result is shown below:

All of the power of the multiple background and border-image syntax is at your disposal when building masks!

As usual leave feedback in the comments and file bugs on any problems you notice at http://bugs.webkit.org/.


[Uncategorized ]
View original post | Add to del.icio.us| Updated 7 months ago | Share

      view feed content CodePlex Daily Summary for Saturday, June 14, 2008 (Web Development Helper )    [1 views, last view 31 d and 20 h ago]
CodePlex Daily Summary for Saturday, June 14, 2008Most Popular Projects

Most Active Projects

New Releases

New Projects



View original post | Add to del.icio.us| Updated 5 months ago | Share


      view feed content CodePlex Daily Summary for Thursday, June 26, 2008 (Web Development Helper )    [1 views, last view 35 d and 7 h ago]
CodePlex Daily Summary for Thursday, June 26, 2008Most Popular Projects

Most Active Projects

New Releases

New Projects



View original post | Add to del.icio.us| Updated 5 months ago | Share


      view feed content Web Inspector Redesign (WebKit Open Source project)    [1 views, last view 39 d ago]

It has been nine months since our last Web Inspector update and we have a lot of cool things to talk about. If you diligently use the Web Inspector in nightly builds, you might have seen some of these improvements, while other subtle changes might have gone unnoticed.

Some of the Web Inspector improvements were contributed by members of the WebKit community. We really want to get the whole community involved with making this the best web development tool available. Remember, most of the Web Inspector is written in HTML, JavaScript, and CSS, so it’s easy to get started making changes and improvements.

Redesigned Interface

First and foremost, the Web Inspector is now sporting a new design that organizes information into task-oriented groups — represented by icons in the toolbar. The toolbar items (Elements, Resources, Scripts, Profiles and Databases) are named after the fundamental items you will work with inside the respective panels.

Console

The Console is now accessible from any panel. Unlike the other panels, the Console is not just used for one task — it might be used while inspecting the DOM, debugging JavaScript or analyzing HTML parse errors. The Console toggle button is found in the status bar, causing it to animate in and out from the bottom of the Web Inspector. The Console can also be toggled by the Escape key.

Error and warning counts are now shown in the bottom right corner of the status bar. Clicking on these will also open the Console.

In addition to the visual changes to the Console, we have also greatly improved usability by adding auto-completion and tab-completion. As you type expressions, property names will automatically be suggested. If there are multiple properties with the same prefix, pressing the Tab key will cycle through them. Pressing the Right arrow key will accept the current suggestion. The current suggestion will also be accepted when pressing the Tab key if there is only one matched property.

Our compatibility with Firebug’s command line and window.console APIs has also been greatly improved by Keishi Hattori (服部慶士), a student at The University of Tokyo (東京大学) who tackled this area as a summer project.

Elements Panel

The Elements panel is largely the same as the previous DOM view — at least visually. Under the hood we have made number of changes and unified everything into one DOM tree.

Resources Panel

The Resources panel is a supercharged version of the previous Network panel. It has a similar looking timeline waterfall, but a lot has been done to make it even more useful.

Scripts Panel

The previous standalone Drosera JavaScript debugger has been replaced with a new JavaScript debugger integrated into the Web Inspector. The new integrated JavaScript debugger is much faster than Drosera, and should be much more convenient.

From the Scripts panel you can see all the script resources that are part of the inspected page. Clicking in the line gutter of the script will set a breakpoint for that line of code. There are the standard controls to pause, resume and step through the code. While paused you will see the current call stack and in-scope variables in the right-hand sidebar.

The Web inspector has a unique feature regarding in-scope variables: it shows closures, “with” statements, and event-related scope objects separately. This gives you a clearer picture of where your variables are coming from and why things might be breaking (or even working correctly by accident).

Profiles Panel

The brand new JavaScript Profiler in the Profiles panel helps you identify where execution time is spent in your page’s JavaScript functions. The sidebar on the left lists all the recorded profiles and a tree view on the right shows the information gathered for the selected profile. Profiles that have the same name are grouped as sequential runs under a collapsible item in the sidebar.

There are two ways to view a profile: bottom up (heavy) or top down (tree). Each view has its own advantages. The heavy view allows you to understand which functions have the most performance impact and the calling paths to those functions. The tree view gives you an overall picture of the script’s calling structure, starting at the top of the call-stack.

Below the profile are a couple of data mining controls to facilitate the dissection of profile information. The focus button (Eye symbol) will filter the profile to only show the selected function and its callers. The exclude button (X symbol) will remove the selected function from the entire profile and charge its callers with the excluded function’s total time. While any of these data mining features are active, a reload button is available that will restore the profile to its original state.

WebKit’s JavaScript profiler is fully compatible with Firebug’s console.profile() and console.profileEnd() APIs, but you can also specify a title in console.profileEnd() to stop a specific profile if multiple profiles are being recorded. You can also record a profile using the Start/Stop Profiling button in the Profiles panel.

Databases Panel

The Databases panel lets you interact with HTML 5 Database storage. You can examine the contents of all of the page’s open databases and execute SQL queries against them. Each database is shown in the sidebar. Expanding a database’s disclosure triangle will show the database’s tables. Selecting a database table will show you a data grid containing all the columns and rows for that table.

Selecting a database in the sidebar will show an interactive console for evaluating SQL queries. The input in this console has auto-completion and tab-completion for common SQL words and phrases along with table names for the database.

Search

Accompanying the task-oriented reorganization, the search field in the toolbar now searches the current panel with results being highlighted in the context of the panel. Targeting the search to the current panel allows each panel to support specialized queries that are suited for the type of information being shown. The panels that support specialized queries are Elements and Profiles.

The Elements panel supports XPath and CSS selectors as queries in addition to plain text. Any search you perform will be attempted as a plain text search, a XPath query using document.evaluate() and a CSS selector using document.querySelectorAll(). All the search results will be highlighted in the DOM tree, with the first match being revealed and selected.

The Profiles panel supports plain text searches of the function names and resource URLs. Numeric searches are also supported that match rows in the profile’s Self, Total and Calls columns. To facilitate powerful numeric searching, there are a few operators and units that work to extend or limit your results. For example you can search for “> 2.5ms” to find all the functions that took longer than 2.5 milliseconds to execute. In addition to “ms”, the other supported units are: “s” for time in seconds and “%” for percentage of time. The other supported operators are “< ”, “<=”, “>=” and “=”. When no units are specified the Calls column is searched.

In all the panels pressing Enter in the search field or ⌘G (Ctrl+G on Windows and Linux) will reveal the next result. Pressing ⇧⌘G (Ctrl+Shift+G on Windows and Linux) will reveal the previous result. In the Resources, Scripts and Profiles panels the search will be performed on the visible view first and will automatically jump to the first result only if the visible view has a match.

Availability and Contributing

All of these things are available now in the Mac and Windows nightly builds. Give them a try today, and let us know what you like (or don’t like).

If you would like to contribute, there are some really interesting tasks in the list of Web Inspector bugs and enhancements, and other contributors in the #webkit chat room are pretty much always available to provide help and advice.


[Uncategorized debugger inspector profile profiler web inspector ]
View original post | Add to del.icio.us| Updated 57 d ago | Share

      view feed content CodePlex Daily Summary for Friday, August 01, 2008 (Web Development Helper )    [1 views, last view 41 d ago]
CodePlex Daily Summary for Friday, August 01, 2008Most Popular Projects

Most Active Projects

New Releases

New Projects



View original post | Add to del.icio.us| Updated 4 months ago | Share


      view feed content CodePlex Daily Summary for Saturday, July 26, 2008 (Web Development Helper )    [1 views, last view 44 d ago]
CodePlex Daily Summary for Saturday, July 26, 2008Most Popular Projects

Most Active Projects

New Releases

New Projects



View original post | Add to del.icio.us| Updated 4 months ago | Share


      view feed content CodePlex Daily Summary for Tuesday, June 03, 2008 (Web Development Helper )    [1 views, last view 46 d ago]
CodePlex Daily Summary for Tuesday, June 03, 2008Most Popular Projects

Most Active Projects

New Releases

New Projects



View original post | Add to del.icio.us| Updated 6 months ago | Share


      view feed content CodePlex Daily Summary for Friday, June 06, 2008 (Web Development Helper )    [3 views, last view 47 d ago]
CodePlex Daily Summary for Friday, June 06, 2008Most Popular Projects

Most Active Projects

New Releases

New Projects



View original post | Add to del.icio.us| Updated 5 months ago | Share


      view feed content Public / Suggestions (Companion.JS)    [4 views, last view 47 d ago]

New : You can now use the Forum to send suggestions and discuss them with the community.

You can add here all the features you would like to have on future versions :

DebugBar

Good point ! I will try to add the "text/xml" and "text/xsl" content display. For the hex viewer, I will keep it for a future version.

Already done : Using Companion.JS you can have console.log() feature from javascript !

DebugBar will be unicode in the next release

S. Stock (I'm using DebugBar v4.1b2)

We will try to add it in a future release

Already in the todo (second suggestion at the top of the page)

You can try Companion.JS which gives more detailled info about JS errors under IE

Hmm... You are right, but I don't know if I will be able to add it on a future release (not technically difficult, but a lot of work). I will keep you informed through the wiki.

Ricardo

This will be changed in the next release (v5.0 beta 1).

This will be changed on the next DebugBar release

Scheduled for some day, but not priority so far...

S. Bilodeau

Compagnon.JS

FremyCompany say:

This is already done in Companion.JS : The error on the right can be expanded as a tree to view the call stack.

Mark Roeling:

It would be nice to have some documentation like http://www.getfirebug.com/docs.html. What are the available console / code commands?

You are right. We know we need to do it (!).

Nazir Khan:

I am unable to modify the text, for ex: I have the following code in my web page, i could not able to modify "This is text"

<SPAN title="This is title">This is text</SPAN>

This feature is scheduled in future versions. Stay tuned !

S. Stock :

Are you talking about the "console" tab on the Companion.JS tool ? If so, yes, adding a button to clear the log is a good idea. I will try to add it as an entry in the context menu.

No, I'm talking about the "source" tab and the error messages on the right side. After a while of debugging I have a lot of old error messages in there...

But I guess it would also be good to have a clear button on the console tab.

Really strange, this should be cleared at each new page. Maybe you are using ajax requests to update your page. In this case, there is no "page" reload so it is not cleared. I will add a "clear" feature on the next release ;-)

Right... I could add this to debugbar installer to install Companion.JS as an option. I will try to integrate that on the next release.

Goto line of code

If you have an error it could show a button to go to directly to the line of the code that generated that error.

This will save a lot time! Tks, Gian - gian.peduto at gmail.com

It already exists : You can use Companion.JS which gives detailled info (with line numer and source code) as well as stack trace of the error !. This is an alpha version and will improve soon.



View original post | Add to del.icio.us| Updated more than one year ago | Share

      view feed content Public / Bugs (Companion.JS)    [2 views, last view 54 d ago]

New : You can now use the Forum to post bugs.

1. Google Maps API example

On Win XP Prof, Polish edition, IE 7.0

"Wystąpił błąd w czasie wykonywania. Czy chcesz debugować?

Wiersz: 687 Błąd: Arg: Fraction out of range (0 to 1 allowed)"

==> More details: http://nhw.pl/wp/2007/03/27/ie-errors-with-gpolyline-one-more-word/

We couldn't reproduce the bug on our side. If somebody else is having the same problem, please let us know !

2. Compatibility Issue with IE7Pro (AdBlocker part)

When I'm installing the DebugBar, the AdBlocker stop working... I wonder whether it is not the observation of the requests HTTP which makes doubled bloom (indeed, IE7Pro makes it possible to block some url download)

We will check this problem soon...

3. This code break the code highlight String.escape=function(string) {return string.replace(/('|\\)/g,"\\$1");}}

This is a known bug/limitation of our current code highlighter. We will try to fix it in a future release, but this is not a priority task so far. Thank you for the feedback anyway.

4. I installed the Beta version, i dont see anything popultaed in the HTTP(S) tab at all. Rest of the tabs work fine. IS there anything in the IE that i have to set to see the http/https information?

Sometimes, IE is disabling the DBB BHO used to get the HTTP info. Check on the IE "Manage add-ons" dialog box if it is enable, and if not, enable it. This should solve the problem.

5. I have the same problem that #4: I don't see anything populated in the HTTP(S) tab. I can't use your advice, because I'm using IE 6.0 and I don't have any "Manage add-ons" stuff. Any other suggestion of what can be wrong in my IE configuration?

I tested on win2000 and it is working ok. If you have some time for debugging, you can contact me directly at contact@debugbar.com so we can try to find the problem.

By the way.. I should (will) set up a forum which is more suitable for bug reports and discussions than a wiki !

6. When Companion.JS is actived, a Network Service (SVCHOST.EXE) use 100% of my CPU when it's possible (I've configured my computer to privilege programs and not system) and it make my computer slower

This is a bug on the version 0.1 : The Companion.JS is trying to connect to IE as a debugger every 0.5 seconds. When the script debugging is disabled on IE, this loop is using a lot of CPU :-( We will correct this on the next version.

To avoid the problem (and activate Companion.JS as well!) you can activate script debugging under IE by unchecking the 2 "disable" checkboxes in the IE internet options :

7. DebugBar icons are messed up after changing Windows theme. Tested on Win XP SP2, IE 7.

--Ricardo

Good point. This is a minor bug... but I will try to correct on a future version.

8.

When trying to use Companion.JS, I always see the script debugger window popping up, letting me choose if I want to debug with "Microsoft Script Editor" or "Microsoft Script Debugger". Regardless whether I say yes or no, Companion.JS doesn't receive the errors, the console stays empty. Even worse, when trying to type something into the console, the input area freezes (greyed out).

Is this somehow related to Microsoft Script Editor? I have disabled all three options in the preferences, even the "Show script errors".

Thanks!

--Paul (paul.bakaus at gmail)

Strange, It may depends on the system (I corrected a bug for this under Vista). I will contact you directly to try to correct the bug.

9.

Compagnon.JS

I install everything, follow all instruction but "console.xxx()" doesn't seem to be analysed !? May have someone experiment the same problem ?

Here is a image :

Hoppe you will found a solution !

--Frederic (frederic.klee at bluewin dot ch)

I have the same Problem. On every console.log a error ist thrown I have the problem as well. Every call to console.log gives me 'console is undefined'. This is a new install of ie7 on XP SP2 (new system). It shows the line properly in the source just like Frederic's example. I have installed accoprding to the instructions on the install page.

-- Mark Armendariz (enobrev at gmail dot com)

10.

I have the same problem as Paul in section 8 above. I've installed CJS, unchecked the debug options, but JS errors still insist on popping up the Microsoft choices (debug or script editor). And typing anything in the console freezes up the input box.

Interestingly enough, some errors do get handled by CJS, for instance on Microsoft's own Windows Update page there's a trivial error which does cause CJS to open instead of the strandard MS dialog. But 90% of errors still trigger that dialog instead of CJS.

I'd love to use this product ... so any update on this issue?

I'm running XP (2002), SP2, with IE7, all fully up to date.

edit - PROBLEM SOLVED! It's a .NET v2 Thing. Disable "Just in Time" Debugging by firing up MS Word, go to Tools->Macro->Microsoft Script Editor. In Script Editor, go to Tools->Options->Debugging. Click "JIT Settings". Clear the checkbox for "JIT Debugging". OK the dialogs. Close Word. Restart IE.

-- hugh

Thank you very much for the feedback ! I was trying to understand this problem for a few days so far and couldn't find any solution. I will try to setup a faq for Companion.JS for easier installation.



View original post | Add to del.icio.us| Updated more than one year ago | Share

      view feed content IETester / ChangeLog (Companion.JS)    [2 views, last view 57 d ago]
2008-02-29 : v0.1.3 2008-02-25 : v0.1.2 2008-02-19 : v0.1.1 2008-02-18 : v0.1

View original post | Add to del.icio.us| Updated 8 months ago | Share

      view feed content NEW POST: Error attaching debugger to script (Web Development Helper )    [1 views, last view 67 d ago]
Install the Microsoft Script Debugger then try doing it.  Worked for me.


View original post | Add to del.icio.us| Updated 5 months ago | Share

      view feed content Introducing SquirrelFish Extreme (WebKit Open Source project)    [2 views, last view 69 d ago]

Just three months ago, the WebKit team announced SquirrelFish, a major revamp of our JavaScript engine featuring a high-performance bytecode interpreter. Today we’d like to announce the next generation of our JavaScript engine - SquirrelFish Extreme (or SFX for short). SquirrelFish Extreme uses more advanced techniques, including fast native code generation, to deliver even more JavaScript performance.

For those of you who follow WebKit development and are interested in contributing, we’d like to report our results and what we did to achieve them.

How Fast is It?

This chart shows WebKit’s JavaScript performance in different versions - bigger bars are better.

The metric is SunSpider runs per minute. We present charts this way because “bigger is better” is easier to follow when you have a wide range of performance results. As you can see, SquirrelFish Extreme as of today is nearly twice as fast as the original SquirrelFish, and over 10 times the speed you saw in Safari 3.0, less than a year ago. We are pretty pleased with this improvement, but we believe there is more performance still to come.

Quite a few people contributed to these results. I will mention a few who worked on some key tasks, but I’d also like to thank all of the many WebKit contributors who have helped with JavaScript and performance.

What makes it so fast?

SquirrelFish Extreme uses four different technologies to deliver much better performance than the original SquirrelFish: bytecode optimizations, polymorphic inline caching, a lightweight “context threaded” JIT compiler, and a new regular expression engine that uses our JIT infrastructure.

1. Bytecode Optimizations

When we first announced SquirrelFish, we mentioned that we thought that the basic design had lots of room for improvement from optimizations at the bytecode level. Thanks to hard work by Oliver Hunt, Geoff Garen, Cameron Zwarich, myself and others, we implemented lots of effective optimizations at the bytecode level.

One of the things we did was to optimize within opcodes. Many JavaScript operations are highly polymorphic - they have different behavior in lots of different cases. Just by checking for the most common and fastest cases first, you can speed up JavaScript programs quite a bit.

In addition, we’ve improved the bytecode instruction set, and built optimizations that take advantage of these improvements. We’ve added combo instructions, peephole optimizations, faster handling of constants and some specialized opcodes for common cases of general operations.

2. Polymorphic Inline Cache

One of our most exciting new optimizations in SquirrelFish Extreme is a polymorphic inline cache. This is an old technique originally developed for the Self language, which other JavaScript engines have used to good effect.

Here is the basic idea: JavaScript is an incredibly dynamic language by design. But in most programs, many objects are actually used in a way that resembles more structured object-oriented classes. For example, many JavaScript libraries are designed to use objects with “x” and “y” properties, and only those properties, to represent points. We can use this knowledge to optimize the case where many objects have the same underlying structure - as people in the dynamic language community say, “you can cheat as long as you don’t get caught”.

So how exactly do we cheat? We detect when objects actually have the same underlying structure — the same properties in the same order — and associate them with a structure identifier, or StructureID. Whenever a property access is performed, we do the usual hash lookup (using our highly optimized hashtables) the first time, and record the StructureID and the offset where the property was found. Subsequent times, we check for a match on the StructureID - usually the same piece of code will be working on objects of the same structure. If we get a hit, we can use the cached offset to perform the lookup in only a few machine instructions, which is much faster than hashing.

Here is the classic Self paper that describes the original technique. You can look at Geoff’s implementation of the StructureID class in Subversion to see more details of how we did it.

We’ve only taken the first steps on polymorphic inline caching. We have lots of ideas on how to improve the technique to get even more speed. But already, you’ll see a huge difference on performance tests where the bottleneck is object property access.

3. Context Threaded JIT

Another major change we’ve made with SFX is to introduce native code generation. Our starting point is a technique called a “context threaded interpreter”, which is a bit of a misnomer, because this is actually a simple but effective form of JIT compiler. In the original SquirrelFish announcement, we described our use of direct threading, which is about the fastest form of bytecode intepretation short of generating native code. Context threading takes the next step and introduces some native code generation.

The basic idea of context threading is to convert bytecode to native code, one opcode at a time. Complex opcodes are converted to function calls into the language runtime. Simple opcodes, or in some cases the common fast paths of otherwise complex opcodes, are inlined directly into the native code stream. This has two major advantages. First, the control flow between opcodes is directly exposed to the CPU as straight line code, so much dispatch overhead is removed. Second, many branches that were formally between opcodes are now inline, and made highly predictable to the CPU’s branch predictor.

Here is a paper describing the basic idea of context threading. Our initial prototype of context threading was created by Gavin Barraclough. Several of us helped him polish it and tune the performance over the past few weeks.

One of the great things about our lightweight JIT is that there’s only about 4,000 lines of code involved in native code generation. All the other code remains cross platform. It’s also surprisingly hackable. If you thought compiling to native code is rocket science, think again. Besides Gavin, most of us have little prior experience with native codegen, but we were able to jump right in.

Currently the code is limited to x86 32-bit, but we plan to refactor and add support for more CPU architectures. CPUs that are not yet supported by the JIT can still use the interpreter. We also think we can get a lot more speedups out of the JIT through techniques such as type specialization, better register allocation and liveness analysis. The SquirrelFish bytecode is a good representation for making many of these kinds of transforms.

4. Regular Expression JIT

As we built the basic JIT infrastructure for the main JavaScript language, we found that we could easily apply it to regular expressions as well, and get up to a 5x speedup on regular expression matching. So we went ahead and did that. Not all code spends a bunch of time in regexps, but with the speed of our new regular expression engine, WREC (the WebKit Regular Expression Compiler), you can write the kind of text processing code you’d want to do in Perl or Python or Ruby, and do it in JavaScript instead. In fact we believe that in many cases our regular expression engine will beat the highly tuned regexp processing in those other languages.

Since the SunSpider JavaScript benchmark has a fair amount of regexp content, some may feel that developing a regexp JIT is an “unfair” advantage. A year ago, regexp processing was a fairly small part of the test, but JS engines have improved in other areas a lot more than on regexps. For example, most of the individual tests on SunSpider have gotten 5-10x faster in JavaScriptCore — in some cases over 70x faster than the Safari 3.0 version of WebKit. But until recently, regexp performance hadn’t improved much at all.

We thought that making regular expressions fast was a better thing to do than changing the benchmark. A lot of real tasks on the web involve a lot of regexp processing. After all, fundamental tasks on the web, like JSON validation and parsing, depend on regular expressions. And emerging technologies — like John Resig’s processing.js library — extend that dependency ever further.

A Word About Benchmarks

We have included some performance results, but don’t take our word for it. You can get WebKit nightlies for Mac and Windows and try for yourself.

The primary benchmark we use to track JavaScript performance is SunSpider. Although, like all benchmarks, it has its flaws, we think it is a balanced test that covers many dimensions of the JavaScript language and many types of code. If you look at test by test results, you will see that different JavaScript implementations have their own strengths and weaknesses. Browser vendors and independent testers have been tracking this benchmark.

Next Steps and How You Can Contribute

We believe the SquirrelFish Extreme architecture has room for lots more optimization, and we’d love to see more developers and testers pitch in. Currently, we are looking at how to use the bytecode infrastructure to perform more information gathering at runtime and then using it to drive better code generation, and we are studying ways to make JS function calls faster. There is also a lot of basic tuning work to do to take more advantage of the basic architectural advances in SFX. In addition, we’re interested in having JIT back ends for other CPU architectures.

If you’d like to follow the development of WebKit’s JavaScript engine more closely, we have created the squirrelfish-dev@lists.webkit.org mailing list (subscribe here) and the #squirrelfish IRC channel on the FreeNode IRC network. Stop on by and you can learn more about our plans, and how you can help.

Try it Out

Try it, test it, browse with it. It’s now available in nightlies. We hope the changes we’ve made help improve your experience of the web.

UPDATE: For the curious, here are some comparisons of SFX to other leading JavaScript engines. Charles Ying has comparisons on a few more benchmarks.

UPDATE 2: For those of you who just can’t get enough of our little mascot, click the SquirrelFish below in a recent WebKit nightly for a demo of SVG animation support.


[Uncategorized ]
View original post | Add to del.icio.us| Updated 73 d ago | Share

      view feed content The latest weekly, now with more lingo (Opera Dragonfly)    [1 views, last view 81 d ago]

We’ve just put the latest build of Opera Dragonfly on the weekly branch. New for this release is the infrastructure for localisation. We have plans to release Opera Dragonfly in a number of languages, and this release is focused on testing the infrastructure we’ve put in place. It is supplied with test localisations in Japanese and German. These localisations are examples and not the finalised text for those languages. Opera Dragonfly will load the required language file, depending on the language of your browser.

After this release we are focusing on testing the features added to the new version of the Scope protocol, which will be included in Core-2.2. We need to make sure these work and there are no major bugs before Core-2.2 goes into code freeze. As such there will be no weeklies for a while, until that work has been carried out. After this we can start working on the rest of the features planned for alpha 3, including DOM editing.

The next version of Scope should improve the user experience considerably as Opera Dragonfly will be able to detect the currently focused tab or window, which means there will be less steps to start up. We hope to also allow the user to select an element n the page and have Opera Dragonfly go straight to that element in the DOM inspector. We will also have the basics of the HTTP inspector.



View original post | Add to del.icio.us| Updated 3 months ago | Share