1. Presented by Brian Nicholson
Language Support For Extensible Web Browsers Benjamin S. lerner dan grossman
Presented by Brian Nicholson

2. Key Points Extensions are important
Current extension implementations are insufficient
Languages can be used to address UI conflicts
Aspects can be used to address code conflicts
Extensions have a large user base, and it’s worth investing time to research them
No mention of other browsers

3. Motivation for Extensions
Convenient access to commonly used services
TwitterBar, Yoono: let users quickly publish tweets in response to what they are browsing
Google Toolbar: Gmail indicator and Google search
you don't need to visit a particular page to get functionality

4. Motivation for Extensions
Extensions extend browser functionality
Greasemonkey
AdBlock Plus
FireBug
Greasemonkey is like an extension within an extension
allows users to create scripts without worrying about the extension framework
this is in Firefox (native support in Google Chrome)

5. My Research: LibX
LibX was redesigned from a toolbar to a popup due to Chrome’s constraints

6. My Research: LibX Extensions can be used for almost anything
Thousands of extensions

7. Flexibility vs. Stability
Firefox's approach
Extensions should be able to build on and compliment each other
Chrome's approach
Extensions must be stable and predictable

8. Chrome’s Extension points
Browser actions
Page actions
Themes
Apps
Omniboxes
Options page
Page overrides
Desktop notifications
This is a “pull model”; the browser selectively pulls in specific options it makes available
Stricter, more structured model
Browser_action:
Image source:

9. Chrome’s Extension points
Browser actions
Page actions
Themes
Apps
Omniboxes
Options page
Page overrides
Desktop notifications
This is a “pull model”; the browser selectively pulls in specific options it makes available
Stricter, more structured model
Browser_action:
Image source:

10. Chrome’s Extension points
Browser actions
Page actions
Themes
Apps
Omniboxes
Options page
Page overrides
Desktop notifications
This is a “pull model”; the browser selectively pulls in specific options it makes available
Stricter, more structured model
Browser_action:
Image source:

11. Chrome’s Extension points
Browser actions
Page actions
Themes
Apps
Omniboxes
Options page
Page overrides
Desktop notifications
This is a “pull model”; the browser selectively pulls in specific options it makes available
Stricter, more structured model
Browser_action:
Image source:

12. Browser Button: Chrome
"browser_action": { "default_icon": "libx2-48.png", "popup": "popup/popup.html" }

13. Firefox’s Extension Model
Firefox is overlay-based
No explicit loading order for extensions
Race conditions
No errors if an overlay target is not found
Think of projectors on top of each other; the composite image is the final result
This is a “push” model; you have the base browser, and the extensions decide how to manipulate it
More versatile model; more prone to failures and conflicts

14. Browser Button: Firefox
<toolbaritem id="urlbar-container"> <toolbarbutton id="libx-button“ insertafter="urlbar-search-splitter“ image="chrome://libx/skin/libx2-16.png" /> </toolbaritem>

15. Extending Functionality: Firefox
There is only one scope
AdBlock vs. NoScript
Monkeypatching and wrapping
AdBlock: uses subscription lists as filters for ads
NoScript is an extension that blocks JavaScript from sites that aren't on a whitelist
NoScript got money from installation
NoScript reverted its changes rather quickly, ironic conclusion for an extension focusing on security
They were able to get away with it because they were considered a trusted extension and didn't need review This put Mozilla in an awkward position and people wanted to technically enforce the AMO policy

16. Extending Functionality: Firefox
Wrapping
var oldFoo = window.foo;
window.foo() = function() {
// do something…
return oldFoo.apply(this, arguments); }

17. Extending Functionality: Firefox
Monkeypatching
window.foo = function() {
// … important code …
alert(“bar”); }

18. Extending Functionality: Firefox
Monkeypatching
window.foo.toString()

19. Extending Functionality: Firefox
Monkeypatching
window.foo.toString()
.replace('alert("bar");',
'alert("cheese");');

20. Extending Functionality: Firefox
Monkeypatching
eval(
window.foo.toString()
.replace('alert("bar");',
'alert("cheese");'); );

21. Extending Functionality: Firefox
Monkeypatching
window.foo = eval(
window.foo.toString()
.replace('alert("bar");',
'alert("cheese");'); );

22. Extending Functionality: Chrome
Content scripts
Run in “isolated worlds”
DOM remains the same
An added event listener will be visible to both Chrome and the page
Limited extension communication
- No JavaScript namespace collisions
- Expando properties do not persist, global variables are isolated
- Cannot create a generic messaging client with supplemental extensions
- May not be true anymore (Chrome supports cross-extension messaging)
- Regardless, extension communication is still very limiting compared to Firefox

23. Proposed Implementation
Abstract language for UI conflicts
Guards
Composition operators
Requirements
State of the document
Commutativity
- guards: properties that must hold when the overly is applied
can request that certain parts of the document are unmodified; alternatively, can request that parts are not modified once applied
composition operators: specify ordering constraints
document transformers that define the transformation from the initial state to the final state

24. Proposed Implementation
Abstract language for UI conflicts
Guards
Composition operators
Requirements
State of the document
Commutativity
requirements: targets in the document
state of the document: lists of requirements: requirements that have been defined, requirements that have not been defined, requirements that have not been overlaid, requirements that cannot again be overlaid
Commutativity: if the output of overlay o1 cannot match the required input for o2, o2 must precede o1 and they do not commute

25. Proposed Implementation
Resolving script conflicts
Aspect-oriented approach
Explained in their follow-up paper
“Supporting Dynamic, Third-Party Code Customizations in JavaScript Using Aspects”

26. Aspects Advice: code being “injected” Pointcuts: where to inject it
Inserted into code without requiring any core changes
Ideal for extensions
Implemented using Microsoft JScript compiler
Uses JIT to compile weaving at runtime
Uses code generation to account for aspects
Because aspects essentially modify the function and closures at runtime, the closure needs to be invalidated when aspects are weaved

27. Aspects Before: var oldP = unsafeWindow.P;
unsafeWindow.P = function(iframe, data) {
if (data[0] == "mb")
data[1] = format(data[1]);
return oldP.apply(iframe, arguments); }

28. Aspects After: at pointcut(callee(unsafeWindow.P))
before(iframe, data) {
if (data[0] == "mb")
data[1] = format(data[1]); }
Pointcut: callee(unsafeWindow.P)
where unsafeWindow.P is a function, and callee is the caller of that function
Advice: before {} block

29. Flaws with Aspects Consider 3 functions: f, g, and h
Extend f to always return 32
Extend g to always return 53
Extend h to set f = g
Could cause conflicts
Only detectable dynamically
If 3 runs first, 1 and 2 may conflict since they would be extending the same function to return 2 different values
Browser itself is the only program that can sufficiently analyze this case
even with detection in place, the end-user doesn't benefit much because they can either abort or permit an undetermined action
Static analysis would be better, situation is farfetched
Static analysis would allow users to see potential conflicts beforehand

30. Conclusion
Chrome’s model prevents conflicts, but is limited in capability
Firefox’s model is more open, but is prone to introduce conflicts
Languages can be used to address UI conflicts
Aspects can be used to remedy potential extension code conflicts

31. Questions?