Skip to content

When Fiddler

Nikolay edited this page Nov 18, 2016 · 8 revisions

Intro

The page you see now consists of logical components:

  • Text data itself
  • Logic how to display it (HTML & CSS)
  • Logic how to react on your activity (JavaScript)

blog_pict

Whenever the web page behaves in browser not as you wish, it is time to blame client-side logic!

Is it time to blame client-side logic

It is time to blame client-side logic when:

  • Reaction on your site activity is wrong or missing:
    • Button click results in errors reported in browser console, or does nothing at all
    • A request with wrong data is sent to server side
  • Markup is misaligned
    • Footer is on header place

The situation becomes more challenging when you are unable to reproduce the behavior in another environment/browser :)

You do exactly same steps, but everything works like a charm.

How come

You are definitely missing something, and the trick is to figure out what is missed.

image

Since the reaction is produced by code, it most likely means that either code base, or styles, or steps taken are different.

A common sense gives a hint that exactly same steps with exactly same code and data ought produce same affect.

Thereby something is different in our case.

Fiddler time

Fiddler can record all the browser-server interactions in simple words, and might not need to be installed at all.

It can be configured to record specified hosts only, and capture HTTPS traffic (disabled by default):

image

Our game plan is straightforward - do same actions and record resulting browser-server activities in both environments to compare them later on.

Gotcha 1: Browser cache

Browsers cache static files, so we must use incognito mode to request static file from server rather than using cached copy:

image

Gotcha 2: Exactly same steps

A screencast is needed to ensure exactly same steps are taken.

There are tons of available tools like Jing, Monosnap, Snagit.

Collection time

The following steps are recommended to take:

  1. Ensure Fiddler is configured to capture HTTPS traffic (disabled by default) if your site runs with HTTPS

  2. Start recording screencast and capturing Fiddler session //Get exact match between UI actions & resulting request

  3. Start anonymous (incognito) browser session //Force browser load data instead of using cached copy

  4. Reproduce an issue

  5. Save both Fiddler session ( File->Save all sessions-> *.saz format) and screencast.

  6. Collect same Fiddler session in another environment

Analysis time

Next step is to open sessions in same instance of Fiddler application to find out the differences.

We are going to use Inspectors tab with different views to see why different outcomes for same UI actions are produced:

  • Select 2 similar requests (hold CTRL) produced by different sessions, and compare them (CTRL+W)
  • Analyse cookies, data requested and received to locate the difference via Inspectors
  • Save the different static files output (clickable image):

image

In case alike request parameters result in different responses, it much looks like a server issue =\

Whereas different request parameters (WebForms Inspector tab) would provoke different server output.

Since parameters are formed on browser side, it looks different client-side logic was triggered.

Taking into account the steps taken are same, the JavaScript or CSS difference likely takes place.

It will not take much time to locate the difference by comparing both outputs.

Confirming findings

Once the faulting file is located, you can use Fiddler to respond faulting file instead of correct one to reproduce the issue locally:

image

Further step

You can compare faulting file with the one located on server filesystem:

  • Files are different -> you have solved the case
  • Files are same -> old file cached somewhere in network layer -> you have solved the case

Please do not forget to clear browser cache after addressing the issue to ensure a new JS is actually requested from server :)

Conclusion

Fiddler is very powerful tool that allows to track & analyse the browser-server interaction flow. It has dozens of useful features that would make each Web developer life easier.

In this article I`ve shown basic techniques, however keep in mind that there are more far more possibilities (f.e. replaying the session locally in browser to debug JS).

The more you work with the tool, the more useful functionality you going to discover.

Clone this wiki locally