Friday, 9 November 2012

Some FireFox "about:config: Trick

The "about:config" page where all the setting enumerated in prefs.js and listed in alphabetical order. prefs.js is the file where firefox keeps its all the setting instead of the window's registry. Modification could be done for any purpose like personal, professional and even for the use of selenium. 


To do the modification just open the "about:config" page on url address of firefox. It gives you the power of do the modification as per your requirement. Each setting, or preference, is given a name and stored as a string (text), integer (number) or Boolean (true/false) value as mention in windows registry.




Here are some tweaks which may be useful:
1. Disable Antivirus Scanning

This is mainly for Windows users. By default, Firefox 3 automatically scan the downloaded file with the default anti-virus application to make sure it is free of virus. If you download a big file, it could take a long time for the whole scanning process to complete. To increase the performance of the browser, you might want to consider disabling the anti-virus scanning via thebrowser.download.manager.scanWhenDone key.
Config name: browser.download.manager.scanWhenDone
Default: True
Modified value: False (if you want to disable it)
2.  Configuring The Scrolling Tabs
When you opened many tabs, Firefox will not keep on reducing the tab width. Instead, it shows a scrolling bar so that the min width (100px) is conserved and you can scroll to find your tabs. If you are those who don’t like the scrolling tab function and prefer Firefox to show all the tabs, regardless how small it is, you can set the value of browser.tabs.tabMinWidth to 0 to disable it. Similarly, if you want Firefox to display more tabs before showing the scrolling button, you can reduce the default value to a lower value, say 75 pixels.
Firefox-scrollingtab
Config name: browser.tabs.tabMinWidthDefault: 100
Modified value: Configuring The Scrolling Tabs
 3. Autofill Address in URL Bar
Other than the smart location feature, you can also get your URL bar to autofill the address as you type the URL.


Config name: browser.urlbar.autofill
Default: False
Modified value: True (Have Firefox autofill the address as you type in the URL bar)

4. Select all text when click on the URL bar

In Windows and Mac, Firefox highlights all text when you click on the URL bar. In Linux, it does not select all the text. Instead, it places the cursor at the insertion point. Regardless which platform you are using, you can now tweak it to either select all or place cursor at insertion point.

Config name: browser.urlbar.clickSelectsAll
Modified value:
  • False – place cursor at insertion point
  • True – select all text on click

Wednesday, 20 April 2011

Selenium Invention Story by Huggins


Selenium Invention Story by Huggins


Huggins: Selenium was extracted from a web-based (Python + Plone!) time-and-expense (T&E) application my team and I were building for my previous employer. One of the mandates for the new T&E app was that it needed to be "fast, fast, fast." The legacy application was a client-server Lotus Notes application and wasn't scalable to the current number of offices and employees at the time. To live up to the "fast, fast, fast" design goal, we tried to improve and speed up the user experience as much as possible. For example, expense reports can get pretty long for people who travel a lot. No matter how many default rows we put in a blank expense form, people often needed to add more rows of expense items to their reports. So we added an "Add row" button to the expense report form. To make this "fast, fast, fast," I decided to use a button that triggered JavaScript to dynamically add one blank row to the form. At the time (Spring 2004), however, JavaScript was considered buggy and evil by most web developers, so I caught a lot of flak for not going with the classic approach of POSTing the form and triggering a complete page refresh with the current form data, plus one blank row.
Going down the road of using JavaScript had consequences. For one, we had a really, really difficult time testing that little "Add row" button. And sadly, it broke often. One week "Add row" would be working in Mozilla (Firefox was pre-1.0), but broken in Internet Explorer. And of course, nothing was working in Safari since few developers were allowed to have Macs. ;-) The following week, we'd open a bug saying "'Add row' is broken in IE!!" The developer assigned to the issue would fix and test it in IE, but not test for regressions in Mozilla. So, "Add row" would now be broken in Mozilla, and I'd have to open a ticket saying "'Add row' is now broken in Mozilla!!!". Unlike most other corporate IT shops, we didn't have the luxury of telling all employees to use a single browser, and developers didn't want to manually test every feature in all supported browsers every time. Also, we had a very tiny budget and commercial testing tools were -- and still are -- ridiculously over-priced on a per-seat basis. The T&E project was done the "Agile Way" -- every developer does testing -- so shelling out thousands of dollars per developer for a testing tool wasn't going to happen. Never mind the fact that there were no commercial tools that did what we needed anyway!
After many months of trial and error and various code workarounds, I came to the conclusion I needed a testing tool that would let me functional-test JavaScript-enhanced web user interfaces (aka "DHTML" or now "Ajax"). More specifically, I needed to test the browser UIs: Internet Explorer, Mozilla Firefox, and Safari. There were no commercial apps at the time that could do this, and the only open source option was JsUnit, which was more focused on unit testing pure JavaScript functions, rather than being a higher-level black-box/smoke-test walk through a web app. So we needed to write our own tool. Our first attempt was a Mozilla extension called "driftwood" (never released), coded by Andrew McCormick, another co-worker of mine at the time. It did make testing the "Add row" button possible, but since it was Mozilla-only, it wasn't what we needed for testing in all browsers. Paul Gross and I started over, and I started to educate myself on functional testing tools and techniques and stumbled upon Ward Cunningham's Framework for Integrated Testing (FIT). I originally set out to implement "FIT for JavaScript," but quickly realized we were drifting away from the FIT API, so Selenium became its own thing.