10 Nov 2011

feedPlanet Mozilla

hacks.mozilla.org: Mozilla Hacks Weekly, November 10th 2011

We do like reading in Mozilla's Developer Engagement Team - here are our latest recommendations for you!

Weekly links November 10th 2011

If there is anything you think we should read or know about, don't hesitate to post a comment, contact us on Twitter or through any other mean.
The picks this week are:

Christian Heilmann

A picture of Christian Heilmann A good explanation on Firefox's Full Screen API and of course the 700,000th bug on Firefox's bugzilla.

If you want to read more tips or discuss the web with Christian, he's available on Twitter as @codepo8.

Eric "Sheppy" Shepherd

A picture of Eric 'Sheppy' Shepherd We shipped a new Firefox release this week; get the scoop on what it means for developers.

If you want to read more tips or discuss the web with Eric, he's available on Twitter as @sheppy.

Jeff Griffiths

A picture of Jeff Griffiths The new ThemeRoller app for jQuery Mobile looks awesome!

If you want to read more tips or discuss the web with Jeff, he's available on Twitter as @canuckistani.

Joe Stagner

A picture of Joe Stagner Building Web Pages with Local Storage.

If you want to read more tips or discuss the web with Joe, he's available on Twitter as @MisfitGeek.

Rob Hawkes

A picture of Rob Hawkes Here is the draft report from the W3C Games Community Group Summit in San Francisco earlier this month. After playing with the Joystick API this week I'm excited to see how browsers and game developers can work together to make the Web a viable platform for gaming.

If you want to read more tips or discuss the web with Rob, he's available on Twitter as @robhawkes.

Robert Nyman

A picture of Robert Nyman 25 Secrets of the Browser Developer Tools - a good overview of various web browser developer tools and in-depth information about them.

If you want to read more tips or discuss the web with Robert, he's available on Twitter as @robertnyman.

10 Nov 2011 2:54pm GMT

Jeff Griffiths: HOWTO: Mobile data access in Berlin, Germany

I'm in Berlin this week to attend this weekend's MozCamp EU; because I'm a dork I really really like having some sort of local data network access, in particular for using google maps on my unlocked Android phone. Having mobile data access has completely changed how I travel, I'm much more likely to just really explore a place than I would without access to google maps. So here's my process for getting cheap mobile data in Berlin:

  1. took the U6 -> S line trains to Alexanderplatz to get to the Alexa Mall ( http://g.co/maps/rv2hz, see map below )
  2. went to Media Markt ( think German Best Buy ), bought a FONIC.de 10 euro SIM card
  3. back at the Tryp hotel where I'm staying, I registered online with fonic.de to activate the sim. There is no English localization of the site and my German is terrible so I had a second window open to google translate to get through it.
  4. in order for the data plan to really start, I had to set my Android phone to 'data roaming' mode.

This will get you a flat rate of 500MB of data, plus relatively cheap text and calling! Sadly, you do need to jump online to register the sim, this is definitely less convenient than what I got last month in London, where they sell flat-rate data sims from vending machines at Heathrow.

Alexa / Media Markt:


View Larger Map

10 Nov 2011 1:07pm GMT

hacks.mozilla.org: Accelerating the overall web experience – Mozilla at Velocity Europe

This year's Velocity EU conference had a special presentation round where browser makers talked about the performance of their specific products. I was invited last minute to represent Firefox and originally was asked to show benchmarks, impressive demos and how we compare to others. As browsers get released in very short intervals these days, this doesn't quite make sense any longer - at least to me.

Funnily enough the other browser representatives took the same approach so I was happy to see that we agreed that we are beyond number-comparisons and head to head browser war on performance.

My talk "Accelerating the overall web experience" covered other things, like that the choice of which browser to use lies with the users and there is not much we can do to change that. I also pointed out that users will find a way to make our browsers slow, no matter how hard we try and that in a lot of cases third party add-ons and debugging tools are to blame for an impression of slowness.

I ended by showing how the new developer tools in Firefox empower developers to perform much better in finding bugs and fixing them - a part of performance that is not easily measurable but very important.

You can see the slides here (left+right to go back and forward, down for next bullet point and N to toggle notes) or read them as an HTML page:

There is also an audio recording of the talk on archive.org:

All in all it was good to see that all browsers are getting faster and faster and we all see this as a given rather than a goal.

10 Nov 2011 12:11pm GMT

Gervase Markham: Because It’s Fun

Good free software is a worthy goal in itself, and I hope that readers who come looking for ways to achieve it will be satisfied with what they find here. But beyond that I also hope to convey something of the sheer pleasure to be had from working with a motivated team of open source developers, and from interacting with users in the wonderfully direct way that open source encourages. Participating in a successful free software project is fun, and ultimately that's what keeps the whole system going.

- Karl Fogel, Producing Open Source Software

10 Nov 2011 9:36am GMT

Bonjour Mozilla: Rencontre mozillienne à Latinoware

Latinoware 2011

(Photo : Eduardo)

Cette photo a été prise durant Latinoware. On y voit, de gauche à droite : Armando Neto, Evelyn Urcullú, Lourdes Castillo, Eduardo Urcullú, Reuben Morais, Rodrigo Padula (t-shirt jaune), Fernando Silveira et Guillermo Movia.
Trois communautés se mêlent ici : Paraguay, Brésil et Argentine.
Evelyn et Eduardo avaient caché des enveloppes sur les lieux de l'évènement avec des prix à l'intérieur, chaque personne qui trouvait une enveloppe pouvant réclamer le prix.

Bonjour à tous !


This photo was taken during Latinoware. We can see, from left to right: Armando Neto, Evelyn Urcullú, Lourdes Castillo, Eduardo Urcullú, Reuben Morais, Rodrigo Padula (yellow t-shirt), Fernando Silveira, Guillermo Movia.
There are three communities meeting there: Paraguay, Brazil and Argentina.
Evelyn and Eduardo had hidden some envelope in the event field with prizes inside, everyone that found one, could reclaim the prize.

Bonjour everybody!

10 Nov 2011 9:00am GMT

Meeting Notes from the Mozilla community: Mobile Meeting Minutes: 2011-11-09

Mobile/Notes/09-Nov-2011


< Mobile | Notes

Details

  • Wednesdays - 9:30am Pacific, 12:30pm Eastern, 16:30 UTC
  • Dial-in: conference# 95312
    • US/International: +1 650 903 0800 x92 Conf# 95312
    • US toll free: +1 800 707 2533 (pin 369) Conf# 95312
    • Canada: +1 416 848 3114 x92 Conf# 95312
  • irc.mozilla.org #mobile for backchannel
  • vidyo: Warp Core

Schedule

  • Merge happened yesterday
  • Next merge date is 2011-12-20

Major Topics for This Week

  • A release roadmap for Fennec Native is coming soon
    • Trying to overlap with normal release channels
    • Likely release 1.0 from birch
  • Working on a change to UA
    • The big issue is how do we get websites to send Firefox Mobile ideal content
    • The UA itself is only seen as a step to get better content
    • See bug 701056 for a different approach
  • Landing of the Pan/Zoom patch queue
    • kats/cwiis/dougt/blassey/patrick looking a general test failure
  • Adobe dropping Flash

Application

Native Front-end
Android Platform

Stand ups

Suggested format:

  • What did you do last week?
  • What are working on this week?
  • Anything blocking you?
Snorp
Kats

Last week

  • Started looking at find-in-page, then dropped it for higher priority things
  • Mostly working on the pan-zoom patch queue:
    • Fixed up some pinching/panning behaviour
    • Put up a patch for having per-tab scroll/zoom information
    • Put up a patch for saving/restoring scroll/zoom information for the screenshot
  • This morning: fixed a bug causing crashes on Honeycomb
  • Hopefully figured out what was causing the pan-zoom build to fail tests

Next week

  • Continue working on pan-zoom issues
  • Pick up other P1/P2 issues as needed

Blockers

  • Need to land birch-pan-zoom! Working in patch queues has very high overhead, and generally is FAIL.
GBrown

Last week:

  • mobile network disk cache has been enabled (finally!)
    • 10 M capacity
    • see about:cache
  • build startup cache at package time: works for development environment, but there are complications for nightly builds - discussing with ted and jmaher (bug 696095)
  • network cache compression: testing, analysis in progress

Next week:

  • wrap up startup cache
  • concentrate on disk cache
AlexP
  • Last week
    • Investigated IME bugs: 630576, 632538, 696319, 698419, 698352, 697838, 699465, 667619.
    • Implemented a WIP patch for the bug 630576
    • Finally got a phone with hardware keyboard to work on the HKB-specific bugs
    • Submitted a patch for hardware keyboard bug 697773 "Cannot type in AwesomeBar URL bar with hard keyboard", but this broke the touch mode, so needs another solution.
  • This week
    • Continue working on IME bugs, focus on HKB-specific ones
Chris Lord
GCP
  • Last week: Finished popup doorhangers. Doing some UrlClassifier patches.
  • Now: Finishing up those patches wrt review comments. Will be looking at bugs. If no more urgent issues, will look at Download Manager.
  • Blockers: Nothing
Brian N
  • Last week
    • Search engines
    • Pan/zoom dead space patch
    • Telemetry opt-in UI
  • This week
    • Finish search engines
    • Pan/zoom
  • Blocked on
    • Nothing
Sriram
  • Last Week:
    • Completed the tabs-list as per UI Spec
    • Implemented stacking of doorhangers
    • Moved doorhangers to the top
  • This Week:
    • Landed fixing the "drawable" folders for menu
    • Working on reskinning doorhangers
    • Working on animating tab increment/decrement counter
  • Blockers:
    • Resources for doorhangers from Patryk
WesJ

Last week:

  • Touch events - bug 603008 -> Patches are up. There's a build at http://people.mozilla.com/~wjohnston/fennec_touch.apk if people want to play/compare to others. Report problems in the bug. Waiting for review. Also, the layers stuff breaks the widget half of this in major ways.
  • UA string stuff. Happy to let dicussion continue for another few days. Then want to make a final decision.

This week:

  • Double Tap zoom
  • ? Responsiveness ?
  • More context menu entries

Blocked on:

  • Startup crash for new 'layers' builds
  • UX for context menus. What do we want to keep? Throw out?
LucasR

Last week

  • AwesomeBar screen as per design
  • Favicon caching
  • Misc cleanups

Next week

  • Follow-up bugs on favicon cache and awesome screen
  • Misc bug fixing

Blocked on

  • Nothing.
MBrubeck
Margaret

Last week:

This week:

  • Continue work on form history and about:config
BLassey

Last week:

  • fixed usage of Cursors bug 700218 and bug 700922
  • fixed incorrect screenshot after clearing app data bug 699716 (hasn't landed)
  • fixed usage of AsyncTasks bug 700354 (hasn't landed)
  • fixed screenshot behavior with user defined profiles (for testing) bug 700917
  • added support for overriding package name with test scripts bug 700797

This week:

  • help land patch queue

Blocked on:

  • landing of patch queue
DougT
  • lots of merging
  • lots of reviews
  • lots of meetings
  • Helping land the panning zooming patch queue
  • fixed some of the offline mode bugs we had
MFinkle

Done:

  • More reviews!
  • Landed basic Password Manager prompts
  • Close to asking for review on the new add-ons manager
  • Banging head on mobile UA story

Next:

  • Add support for new DoorHanger features so we can finish PasswordManager w/ Doorhangers
  • Land basic add-on manager rewrite
  • Encourage some additional context menus - great first bugs for contributors!
  • Get around to blogging

See online status

Madhava
  • Last week: Add-ons flow revisions (done), cataloging missing pieces
  • This week: sync setup and pref flow, prefs, bugs open on missing pieces (i.e. these and these
Ian Barlow
  • Last week:
    • Lots of mocks and specs
    • Awesomescreen [1]
    • Tab menu [2]
    • Header / URL Bar states [3]
    • Menu Icons [4] :)
  • This week:
    • UI Reviews, filing bugs
    • Working on new designs for a Start Page, Reading Mode,
  • Blockers: Nope
Patryk Adamczyk

Last Week
+ Door hanger designs: updated as per Sriram request included in bug #698598
+ Add ons: created a flow / mock up designs with various scenarios and attached them to the add ons bug #696532

This Week
Supporting dev in implementation if any new graphics are needed.

Blockers
None

Round Table

Testing

Talos has been random orange since last thursday. We need to address this. I propose we back everything out since the last solid green (Doug's push on Wednesday). People will need to reland their patches after that.

Going forward, we may need a birch sheriff or some other mechanism to make things better.

QA
  • P0, P1 features have all been assigned to Test Owners. Next step, testcases; bug triaging; testday (this friday)
  • Flash is now on Aurora are we still planning on disable by default?
  • Crash report changing from this to more simplified version of Native only crashes.
    • will continue to report and monitor other channels, report is just simplified
    • If there are any more improvements to make it easier to look at please let nhirata know.
    • big crash following the quit - bug 700720 (not in the current report as of yet) Kats got this fixed.
  • Performance :
    • Working with Waverly to crunch numbers
    • cTalbert has stuff automated as can be seen in elancaster's video; missing part is that it needs to log to a server. he will have something towards the end of the week.
Other
  • (aki)
    • Tegras have low wait times + are afaik on par with n900s. Is there anything preventing us from turning off Maemo builds/tests?
    • Who should I speak with re: Android single locale repacks?
    • Do we still have a need for linux qt builds?
    • Do we need mobile desktop builds on checkin on all branches?
    • Now that FF8.0 has shipped, and 7.0 is EOL'd, we're going to close out remaining maemo bugs.
Retrieved from "https://wiki.mozilla.org/Mobile/Notes/09-Nov-2011"

10 Nov 2011 4:00am GMT

Meeting Notes from the Mozilla community: Firefox/Gecko Delivery Meeting Minutes: 2011-11-09

Firefox/Planning/2011-11-09


< Firefox | Planning

« previous week | index | next week »

Planning Meeting Details

  • Wednesdays - 11:00am PDT, 18:00 UTC
  • Mountain View Offices: Warp Core Conference Room
  • Toronto Offices: Fin du Monde Conference Room
  • irc.mozilla.org #planning for backchannel
  • (the developer meeting takes place on Tuesdays)

Video/Teleconference Details - NEW

  • 650-903-0800 or 650-215-1282 x92 Conf# 95312 (US/INTL)
  • 1-800-707-2533 (pin 369) Conf# 95312 (US)
  • Vidyo Room: Warp Core
  • Vidyo Guest URL
REMEMBER
These notes are read by people who weren't able to attend the meeting. Please make sure to include links and context so they can be understood.

<script>if (window.showTocToggle) { var tocShowText = "show"; var tocHideText = "hide"; showTocToggle(); } </script>

Actions from Last Week

  • Blizzard/Juan to come back on compat issues in Firefox 10 from UA version scraping

Schedule & Progress on Upcoming Releases

Firefox Desktop
Release (3.6, 8)
  • Firefox 3.6.24 → 8.0 advertised update is scheduled for 2011-11-17
Beta (9)
  • Going to build for Firefox 9 beta 1 today
    • We normally build on Tuesday, it was delayed due to some migration issues
    • Hopefully pushing to the beta audience on late Thursday or early Friday
      • Depends on QA signoff
  • Big change in Fx9 is Type Inference
Aurora (10)
  • Daily updates are turned off while we qualify the builds / do backouts (as we always do)
  • We must fix bug 700988 before turning on daily updates
Nightly (11)
Firefox Mobile
8
9
  • Need to remove the "Install Aurora" promo (waiting to land)
10
  • Disabling Flash by default
Native UI
Firefox Sync
  • Firefox 10:
    • Improving Sync Set Up - Went into Aurora. Working with Support to make sure we update docs appropriately
  • Firefox 11+:
    • Push to Device - In development. You can play with an add-on here. Signing off on UX
    • Addon Sync - In development, signing off on UX.
    • Java Porting for Sync - is in progress
Add-on Builder
Add-on SDK

Release (1.2 -> Firefox 7, 8)

  • AMO-hosted addons based on SDK 1.1 were repacked to 1.2 last week for Firefox 8 release
  • this repack included locally-developed addons, but future repacks will include only Builder-developed ones, per plans previously announced
  • repack successful for most such addons (several hundred); authors of six with issues were notified

Stabilization (1.3 -> Firefox 8, 9)

  • 1.3b3 test build released yesterday, Tuesday, November 8 with a number of bug fixes
  • 1.3rc1 test build on track for next Tuesday, November 15
  • 1.3 final release on track for Tuesday, November 29
  • 1.2 tests as compatible with Firefox 9 test builds; thus it does not look like we'll need to do a 1.2 -> 1.3 repack

Development (1.4 -> Firefox 9, 10)

  • continues apace, on track to merge to stabilization branch on Tuesday, November 29 and ship on Tuesday, January 10

Feedback Summary

Desktop

Firefox 8

  • Favicons are lost on bookmark bar/many sites. [1]
  • Extensions (especially especially Java Console) but also Roboform, Trusteer, Norton, AVG
  • Some people are reporting that accessing pages from the address bar doesn't work, have to search/use bookmarks.
  • Very weird: Add-ons manager is completely blank (although extensions are there) and the add-on selection screen didn't show. [2]
  • Possibly crashier

General

  • We pushed a snippet (again) that broke Restore previous session from about:home. bug 682944
Mobile

UX & User Research

Market Insights

Competitors
  • Javascript
    • Intel released a beta Firefox extension for their River Trail project, which allows browser Javascript engines to access the vector processing extensions present on most/all multicore CPUs.
  • Adobe Flash
    • Adobe announced they will not continue to develop the mobile Flash browser plug-in, but will rather focus efforts on their AIR platform for mobile.
  • Windows XP / Windows 7
    • Windows XP's market share is starting to decrease more rapidly as enterprises move to (finally) adopt Windows 7. Net Applications said that Windows' market share dropped 2.5% in October alone, and is now at 48%.
  • Windows 8
    • All tile updates/notifications in the Metro interface will be "data-driven", in that they will be pushed from application backends to Microsoft's "Windows Push Notification Service", analogous to Apple's APNS and Google's Cloud to Device Messaging service.
  • IE10
    • The IE10 team provided more detail regarding their implementation of spell-checking in IE10, which will, for commonly-misspelled words, also offer auto-correction. It will also offer full support for the HTML5 spellcheck attribute for content input elements.
  • IE9
    • Microsoft also unveiled a promotion, apparently aimed at Firefox and Chrome users on Vista and Windows 7, where users who upgrade to IE9 can obtain free movie tickets or Hulu streaming, despite the fact that Windows XP users are not permitted to upgrade to IE9.
  • Webkit
    • Recent changes have given Apple's JavaScriptCore another 3.8% speed improvement on Kraken and 3.5% on v8, with parallel tracing added to garbage collection, reducing pauses by 50% in regular usage.
      • Microsoft indicated that one of their upcoming products will require the addition of an allow-popups directive to the iframe sandbox, so the Webkit team added it this week.
      • A compile-time flag has been added for CSS Shaders, indicating that work there will be commencing soon.
  • Google Chrome
    • Google, in their beta channel, released the "sign in to Chrome" feature, allowing, as with Firefox Sync, for profiles to be synchronized across devices and for more than one user to share the same device without commingling bookmarks and other settings.
  • Apple Safari
    • Sencha proclaims that Safari on the iPhone 4s and iOS 5 as providing the best mobile HTML5 developer platform, citing its speedy canvas, WebGL, device compass, web workers, and XHR level 2 support.
  • Bonus: Javascript growth on top websites
    • There's been a 35% growth in average amount of Javascript included on the Top 12,000 websites globally in the last 12 months, as reported by httparchive.org: http://bit.ly/vjTsv2
Mobile

Summary below, full update here and in your inbox.

  • Samsung became the biggest smartphone vendor in Q3, followed by Apple, Nokia, HTC and RIM
  • 44% of all Android devices run on v2.3, with 41% on v2.2 and 11% on v 2.1, but Android fragmentation is a costly business
  • The next version of Google TV will run on Android
  • Adobe will stop working on Flash for mobile
  • Opera announced 131 million users for Opera Mini and released platform stats
  • Sony now fully owns SonyEricsson, and new rumours of WebOS acquisition surface
  • Quad-core Tegra 3 phones are on their way

Marketing, Press & Public Reaction

Questions, Comments, FYI

  • Christian announced a script to scrape input and generate CSVs last week. There was a bug in it for certain types of queries
    • Cheng was right! We generally have more negative feedback than positive in input
      • There is surely selection bias in there so the more interesting information is trends and comparing various Firefox versions
    • If you are using the script, make sure you have the latest, which is confirmed fixed
  • I think I remember hearing that Fx 9 might be the last XUL version of Firefox mobile. Is that still the plan? Will Firefox 10 be the native UI version of mobile that's on nightlies now?
  • Myk: I started the Jetpack Features working group to investigate the feasibility of shipping core Firefox features as default addons built with the Add-on SDK.
  • If you're going to a MozCamp, make sure to point people excited about NativeUI to the new Mobile Test Drivers Program (http://www.mozilla.org/mobile/testdrivers).

Actions this week

  • Johnathan to talk to engagement about bug 682944, and our process for snippet QA
Retrieved from "https://wiki.mozilla.org/Firefox/Planning/2011-11-09"

10 Nov 2011 4:00am GMT

Mozilla IT: This week in IT: early holiday shopping

Mozilla is growing, and we have to grow our infrastructure right along with it. A lot of this just happens behind the scenes as we are buying and installing new gear every month. For today's post I thought I would give an insight into the broad range of servers we have in the ordering/shipping process right now.

if only it were this easy...

On a logistical note, we are getting a new block of space in our Phoenix data center that all of this gear will go in once it is ready (except for the China servers). We are close - just a few more pieces to that puzzle and we will start racking this new gear.

That's all for now, it is time to get back to obsessing over FedEx trackers and logistical details. Next week, we invent teleportation.

10 Nov 2011 3:25am GMT

hacks.mozilla.org: insertAdjacentHTML() Enables Faster HTML Snippet Injection

The following is a guest post by Henri Sivonen:

In Firefox 8, we've added support for insertAdjacentHTML(). It's an ancient feature of Internet Explorer that has recently been formalized in HTML5 and then spun out into the DOM Parsing specification. The bad news is that Firefox is the last major browser to implement this feature. The good news is that since other major browsers implement it already, you can start using it unconditionally as soon as the Firefox 8 update has been rolled out to users.

Basic Usage

insertAdjacentHTML(position, markup) is a method on HTMLElement DOM nodes. It takes two string arguments. The first argument is one of "beforebegin", "afterbegin", "beforeend", or "afterend" and gives the insertion point relative to the node that insertAdjacentHTML() is invoked on. The second argument is a string containing HTML markup that gets parsed as an HTML fragment (similar to a string assigned to innerHTML) and inserted to the position given by the first argument.

If the node that insertAdjacentHTML() is invoked on is a p element
with the text content "foo", the insertion points would be where the comments are in the following snippet:

<!-- beforebegin --><p><!-- afterbegin -->foo<!--
beforeend --></p><!-- afterend -->

The "beforebegin" and "afterend" positions work only if
the node is in a tree and has an element parent.

For example, consider the following code:

<div id=container><p id=para>foo</p></div>
<script>
  document.getElementById("para").insertAdjacentHTML("beforeend", "<span>bar</span>");
  console.log(document.getElementById("container").innerHTML);
</script>

This code produces this log output:

<p id="para">foo<span>bar</span></p>

Well, that does not look particularly special. In fact, it looks like something that could have been done using plain old innerHTML. So why bother with insertAdjacentHTML() when element.innerHTML += "markup"; already works?

There are two reasons.

Avoiding DOM corruption

Let's consider the DOM corruption issue first. When you do element.innerHTML += "markup";, the browser does the following:

  1. It gets the value of innerHTML by serializing the descendants of element.
  2. It appends the right hand side of += to the string.
  3. It removes the children of element.
  4. It parses the new string that contains the serialization of the old descendants followed by some new markup.

The old descendants might have been script-inserted to form a subtree that doesn't round-trip when serialized as HTML and reparsed. In that case, after the operation, the tree would have a different shape even for the "old" parts. (For example, if element had a p child which in turn had a div child, the subtree wouldn't round-trip.) Furthermore, even if serializing and reparsing resulted in a same-looking tree, the nodes created by the parser would be different nodes than the nodes that were children of element at first. Thus, if other parts of the JavaScript program were holding references to descendants of element, after element.innerHTML += "markup"; had been executed, those references would point to detached nodes and element would have new similar but different descendants.

When additional content is inserted using insertAdjacentHTML(), the existing nodes stay in place.

Better performance

Serializing and reparsing is also what leads to performance problems with the element.innerHTML += "markup"; pattern. Each time some more content is appended, all the existing content in element gets serialized and reparsed. This means that appending gets slower and slower, because each time there more and more previous content to serialize and reparse.

Using insertAdjacentHTML() can make a big difference. For testing purposes, I started with an empty div and ran a loop that tried to append as many tweets as possible to the div in five seconds. A tweet is actually rather large when you count all the mark-up that implements @mention linkification, the name of the tweeter, retweet and favoriting UI, etc. It weighs about 1600 characters of HTML source-most of it mark-up.

On the computer that I used for testing, the innerHTML way of appending managed to append only slightly over 200 tweets in five full seconds. In contrast, the insertAdjacentHTML("beforeend", ...) way of appending managed to append almost 30,000 tweets in 5 seconds. (Yes, that's hundreds versus tens of thousands.) Obviously, real Web apps should never block the event loop for five seconds-this is just for benchmark purposes. However, this illustrates how the innerHTML way of appending becomes notably slower as more and more content accumulates to be serialized and reparsed each time.

At this point, some readers might wonder if insertAdjacentHTML() offers any benefit over createContextualFragment(). After all, conceptually insertAdjacentHTML() creates a fragment and inserts it.

Using createContextualFragment(), my test manages only slightly over 25,000 tweets in five seconds, while using insertAdjacentHTML() manages slightly under 30,000. This is because Gecko accelerates insertAdjacentHTML() when the insertion point has no next sibling (only for HTML though-not for XML so far). The "beforeend" insertion point never has a next sibling and is always accelerated (for HTML). The "beforebegin" insertion point always has a next sibling (the node that insertAdjacentHTML() was invoked on) and is never accelerated. For "afterbegin" and "afterend", whether the operation is accelerated depends on the situation.

In conclusion, you can make your Web app perform better by using element.insertAdjacentHTML("beforeend", "markup"); where you currently use element.innerHTML += "markup";.

10 Nov 2011 3:02am GMT

Robert Accettura: On The Future Of Flash

Adobe is killing Flash, as a plugin for mobile. This shouldn't come as a surprise to anyone who works on the web. Anyone who knows me knows I've bet on HTML5 since the beginning and haven't been ashamed to say it. I don't do Flash. To quote Adobe:

Our future work with Flash on mobile devices will be focused on enabling Flash developers to package native apps with Adobe AIR for all the major app stores. We will no longer continue to develop Flash Player in the browser to work with new mobile device configurations (chipset, browser, OS version, etc.) following the upcoming release of Flash Player 11.1 for Android and BlackBerry PlayBook.

I strongly suspect that even this use case is limited and will experience the same fate as the Flash plugin within the next 24-36 months. HTML5 is supported by browsers, a browser is shipped with the OS and is highly optimized for what it's running on. It's also the ultimate in cross-platform. Why write Flash when you can do something for every platform and not rely on a vendor to abstract you?

Platforms like PhoneGap bridge the world of Apps and HTML5 quite nicely. Adobe bought Nitobi which develops PhoneGap, but PhoneGap is also going to Apache Software Foundation which means Adobe's ability to derail the project would be somewhat limited if they wanted to go that route.

Quite a few Apps use HTML/JS extensively already. HTML5′s success is despite Apple essentially crippling the use of HTML5 in native apps by preventing UIWebView from taking advantage of the Nitro engine. If/when Apple gets to fixing this another barrier will be gone. I suspect Apple will eventually make scrolling that doesn't suck on iOS easier. Right now Joe Hewitt's Scrollability is likely your best bet.

Adobe goes on to say:

However, HTML5 is now universally supported on major mobile devices, in some cases exclusively. This makes HTML5 the best solution for creating and deploying content in the browser across mobile platforms. We are excited about this, and will continue our work with key players in the HTML community, including Google, Apple, Microsoft and RIM, to drive HTML5 innovation they can use to advance their mobile browsers.

Interestingly they left out that little browser vendor Mozilla. Perhaps because they are most likely targeting WebKit on mobile and that's the common tie between those companies sans-Microsoft which they need IE support. If Adobe wants a future here they should learn quick that you can't ignore platforms. My advice to Adobe is to make sure their solution allows developers to bring their product to any modern browser on any device.

Flash is the last plugin with real usage even on the desktop. This is the first step towards the concept of plugins in the browser going away. It's unlikely many will see a need to go HTML5 on mobile and develop a separate Flash code base to do the same thing on a desktop. The name of the game these days is write once, run anywhere (credit to Sun for the slogan). Today marks the start of the decline of Flash.

As Brendan Eich best put it: "Always bet on JavasScript". I have and I continue to do so. The Open Web is winning. Slowly but surely.

Comment Count

10 Nov 2011 2:30am GMT

hacks.mozilla.org: Screencast: BrowserID login flow on OpenPhoto.me

BrowserID is an initiative to provide the web with a better way to sign in. The web is a connected collection of resources and you should not have to have a user name and password for each of them when you could use the web instead.

Today we show you a screencast of how easy BrowserID makes it to login to a web site. For this, we'll look at how the login flow for an existing BrowserID user works the first time they log in on a new website. Our example website is OpenPhoto, a hot new photo sharing app that keeps users in control of their data.

Screencast of logging into OpenPhoto with BrowserID

Get involved:

BrowserID needs your help to grow and become a weapon of choice in the fight against insecure and annoying login systems. The great thing is that now is the time where you can be part of this.

10 Nov 2011 1:03am GMT

09 Nov 2011

feedPlanet Mozilla

Chris Pearce: Mozilla full-screen API progress update

Update 10 November 2011: the full-screen API has been changed slightly and enabled in Firefox Nightly builds, see http://blog.pearce.org.nz/2011/11/firefoxs-html-full-screen-api-enabled.html for details.

I've been working on implementing Robert O'Callahan's HTML full-screen API proposal in Firefox (bug 545812). Support for the base API has landed, disabled by default, in Firefox nightly builds. To enable the full-screen API, set the pref full-screen-api.enabled to true.

We have implemented a general purpose full-screen API which can make any HTML element the full-screen element (it seems WebKit based browsers' full-screen API allow only making <video> elements full-screen).

This feature makes the following API changes to HTML Element:
  1. void mozRequestFullScreen() : makes an HTML element the full-screen element. Causes browser chrome to hide, and expands the element to encompass the entire screen. Upon success, this dispatches a "mozfullscreenchange" event to the requesting full-screen element, or the element's owner document if the element is not in a document. We only grant requests for full-screen when running in user-generated event handlers, e.g. a mouse click handler.
This feature makes the following API changes to HTML Document:
  1. void mozCancelFullScreen() : exits the document from full-screen mode.
  2. readonly attribute mozFullScreen : true when the document is in full-screen mode.
  3. readonly attribute mozFullScreenElement : reference to the current full-screen element, if it's in the current document.
This feature adds the :-moz-full-screen css pseudo class, which applies to the full-screen element while in full-screen mode.

For a request for full-screen to be granted in content inside an iframe, the containing iframe needs to have the mozallowfullscreen attribute present. This is a boolean attribute, so the attribute only needs to be present, it doesn't matter what value it's set to.

Keyboard input is restricted in full-screen mode. When alpha-numeric key input occurs in full-screen mode, full-screen mode immediately exits. This is to help protect against phishing attacks.

We also plan to deny requests for full-screen mode when windowed plugins are present (since we can't easily monitor key events to windowed plugins on non-MacOSX platforms). We will exit full-screen mode when a windowed plugin is added to a document as well. I have a patch for this, but its dependencies haven't landed yet.

Work remaining to be done before this can be enabled:
  1. Adding a warning message when we enter DOM full-screen mode (on desktop Firefox, and on Fennec too).
  2. Making the full-screen API work in multi-process Firefox/Fennec (bug 684620). This requires a way of getting the PBrowserParent from C++ in the chrome process to be implemented, there's not a way to do that yet unfortunately.
  3. Make change/open tab cause full-screen mode to exit (bug 685402).
  4. A security review must be completed, and concerns raised there must be addressed. This could involve changing the API.
We also want a clearer transition effect when entering full-screen, to somehow show the full-screen element "stretching out" to encompass the screen.

You can test out our work-in-progress full-screen implementation, by grabbing the latest Firefox nightly build, setting the pref full-screen-api.enabled to true, and pointing your browser at my not-very-exciting full-screen API demo page.

09 Nov 2011 10:43pm GMT

Chris Pearce: Firefox's HTML full-screen API enabled in Nightly builds

A few days ago I enabled the HTML full-screen API in Firefox nightly builds. This enables developers to make an arbitrary HTML element "full-screen", hiding the browser's UI and stretching the element to encompass the entire screen. This will be particularly useful for HTML5 video and games.

If all goes well, this feature will ship in Firefox 10 at the end of January.

The API has changed slightly since I last blogged about it. The current API is Mozilla-specific, and similar to the W3C's Fullscreen draft specification.

To enter full-screen mode, call the following method on the HTML Element you'd like to enter full-screen:
  • void mozRequestFullScreen() : posts an asynchronous request to make the HTML element the full-screen element. If the request is granted, some time later a bubbling "mozfullscreenchange" event is dispatched to the element which requested full-screen. If the request is denied, a "mozfullscreenerror" event is dispatched to the element's owning document. We only grant requests for full-screen when:
    • mozRequestFullScreen() is called in a user-generated event handler, e.g. a mouse click handler, and
    • the requesting element is in its document, and
    • there are no windowed plugins present in the page or parent/ancestor pages, and
    • all iframes containing the requesting element (if any) have the mozallowfullscreen attribute.
We added the following method and attributes to HTML Document:
  • void mozCancelFullScreen() : exits the document from full-screen mode.
  • readonly attribute boolean mozFullScreen : true when the document is in full-screen mode.
  • readonly attribute Element mozFullScreenElement : reference to the current full-screen element.
  • readonly attribute boolean mozFullScreenEnabled : returns true if calls to mozRequestFullScreen() would be granted in the current document. This returns false if there are windowed plugins present in the page or parent/ancestor pages, or any iframes containing this document don't have the mozallowfullscreen attribute present, or if the user has disabled the API by preference. If this returns false you may want to not show the user your enter-full-screen button in your web page's, since you know it won't work!
We also added the :-moz-full-screen css pseudo class, which applies to the full-screen element while in full-screen mode.

We added the mozallowfullscreen attribute to iframe elements. Without this, full-screen requests made by script in the iframe's content (i.e embedded ads, or a YouTube player in an iframe for that matter) will be denied.

While in full-screen mode, the user can press the ESC key (or F11) to exit. Alpha-numeric keyboard input while in full-screen mode causes a warning message to pop-up to guard against phishing attacks. The only key input which doesn't cause the warning message to pop up are: left, right, up, down, space, shift, control, alt, page up, page down, end, home, tab, and meta.

Navigating, changing tab, changing app (ALT+TAB) while in full-screen mode will cause full-screen mode to exit.

Here's about a simple example, which will work in current Firefox nightly builds:




(Press ESC to exit full-screen)

The code for that button's onclick handler is simply:
document.getElementById('bruce_video').mozRequestFullScreen();

How is Firefox's full-screen API different from Webkit/Chrome/Safari's full-screen API? Firefox's API adds a "width: 100%; height: 100%;" CSS rule to the element which requests full-screen, so that it's stretched to occupy the entire screen. Chrome's API does not do this, but instead it centers the full-screen element in the window and blacks-out the underlying webpage. So the full-screen element won't occupy the entire screen with Chrome's API unless you specify a "width: 100%; height: 100%;" rule yourself. Conversely if you want to vertically and horizontally center something while in full-screen with Firefox's API, you need to make the containing element of your desired centered element full-screen instead, and apply CSS rules to vertically and horizontally center the contained element.

For a cross-browser full-screen API example, see html5-demos.appspot.com's full-screen demo.


09 Nov 2011 10:39pm GMT

Jeff Walden: Introducing MOZ_DELETE, a macro improving upon the deliberately-unimplemented method idiom

C++ default operators and the sole-ownership idiom

Often a C++ class will solely manage some value: for example, a GtkWindow* or a void* for malloc'd memory. The class will then release ownership in its destructor as appropriate. It would be extremely problematic to release ownership multiple times - think security-vulnerability-problematic. C++ copy construction and default assignment exacerbate this issue, because C++ automatically generates these methods for all classes, even when the default behavior breaks sole-ownership. The C++98 idiom solving this is to privately declare a copy constructor and a default assignment operator, then never define them:

struct Struct
{
  private:
    Struct(const Struct& other);
    void operator=(const Struct& other);
};

Declaring the methods privately prevents any code but friends of Struct from calling them. And by never defining them, even such friends will cause a link-time error if they try.

Disabling the default operators in C++11

Once you're familiar with this idiom it's not too bad. But initially, it's pretty unclear. And nothing prevents someone from actually defining these methods. (They could only be used by Struct or friends of Struct, to be sure, but for sufficiently complex code it's possible someone might make a mistake.) C++11 improves upon this trick by introducing deleted function syntax:

struct Struct
{
  private: // no longer necessary, but doesn't hurt
    Struct(const Struct& other) = delete;
    void operator=(const Struct& other) = delete;
};

Deleted functions are effectively removed from name lookup: using, defining, or referring to a deleted function produces a compile error - far better than a link error or, even worse, no error at all.

= delete support in MFBT

The Mozilla Framework Based on Templates now includes support for declaring a function only to prevent its use (or use of an inherited version). The MOZ_DELETE macro encapsulates this support:

#include "mozilla/Types.h"

struct Struct
{
  private:
    Struct(const Struct& other) MOZ_DELETE;
    void operator=(const Struct& other) MOZ_DELETE;
};

MOZ_DELETE isn't as readable or understandable as = delete, but it's searchable, and the comment next to its definition will clarify matters. If the declarations are private, MOZ_DELETE is just as good as the traditional idiom, and in compilers supporting C++11 deleted functions it's better.

Which compilers support C++11 deleted functions? I'm aware of GCC since 4.4, Clang since 2.9, and ICC since 12.0. Rightly, if unfortunately, you must specify -std=c++0x or similar to use deleted function syntax without causing a warning. For various reasons Mozilla can't do that yet, so MOZ_DELETE only produces the C++11 syntax when compiling with Clang (where we can pass -Wno-c++0x-extensions to disable the warning). I'd love to see it use C++11 syntax in GCC and ICC as well, but I don't have the time to solve the -std=c++0x problem now, or to figure out another workaround. I've filed bug 701183 for this problem - help there is much appreciated.

Summary

Use MOZ_DELETE when declaring any method you will intentionally not implement. It'll work better, and produce better errors, in some compilers. Those compilers don't include GCC or ICC yet, but with your help they could. Any takers?

09 Nov 2011 10:12pm GMT

Luke Crouch: MDN Agile and status

tl;dr: We're settling into an Agile process for MDN with daily standups and weekly planning. In the last few months we've added and enhanced developer profiles, events, demos dev derby, and other MDN features. We've also restored, added, and enhanced drafts, review flags, search, article properties, section editing, and authentication in the new wiki. I'll try to write status posts more frequently - each time we make a release, if possible.

AgileAgile

Since my last MDN & Kuma progress post, we've settled into a regular, yet customized, Agile methodology in the MDN team with our agile Bugzilla JS tool. We've pushed MDN 0.9.8, 0.9.9, 1.0, 1.1, 1.2, 1.3, 1.4, and 1.5 thru it relatively smoothly. We've learned and adapted a few techniques in our Agile process worth noting:

Daily standups on IRC

  1. What have you done since we last met?
  2. What do you plan to do until we meet next?
  3. Are you blocked by anything?

By far the 3rd question here is the most important. The first questions are mostly intended to lead into the 3rd. Our scrum-master (now me) is tasked with removing any and all blockers as much as possible - usually chasing down people in other groups from whom we need something (IT, DevEngage, Legal, Security, etc.)

(Bi-)Weekly Retro & Planning Poker

We push code on Tuesdays, so we alternate between post-/pre- and mid-sprint planning meetings. Mid-sprint planning meetings are shorter and faster, little more than a standup. We use an etherpad template for a running minutes of our weekly Wednesday meetings. The basic format is:

  1. Retro - what's go[(ing)|(ne)] good or bad in the sprint?
  2. Discuss - general items to discuss, usually flowing from Retro
  3. Planning (post/pre-sprint only) - re-assess bugs carried over from previous sprint, use planningpoker.com to estimate the current sprint backlog in bugzilla

Test Chamber ProgressStatus

We're developing major features for both MDN and the upcoming wiki.

MDN

I enjoy enhancing MDN in addition to building the new wiki system. The wiki is important and should help us take more control over our docs, but it's still behind-the-scenes; I like shipping code to a production site that helps people, especially developers, immediately.

Wiki

We hope to soon (by the end of the year) run the new wiki side-by-side with MindTouch so we can work from a single line of code and allow testers to compare MindTouch with the new wiki on the same server. But so far we've developed the following features on the separate kuma wiki staging server:

The wiki work is going pretty well, but we still have a couple of major hurdles to clear: data migration & user scripting. We are already investigating data migration a bit, and once we start migrating data over it should help direct our work on user scripts. In my opinion, we can see light at the end of the tunnel but we're still watching out to avoid potential train-wrecks.

The rest

Outside of MDN, I helped pull together an HTML5 track for Tulsa Tech Fest, helped organize a Tulsa Hackathon with Tulsa Web Devs, and I participated in Startup Weekend Tulsa. At SWT we started a quick web app on top of the TRIF project from Hackathon called OttoZen to send an SMS alert to someone when there's a traffic incident on their commute. It's making us consider building a broader Data/App site for Oklahoma. We'll see.

From now on I'll try to make a status post every time we make an MDN release.

09 Nov 2011 10:03pm GMT

hacks.mozilla.org: State of the Docs, November 9, 2011

This is the first in a series of posts about new or recently improved content on MDN. This series will alternate with Wiki Wednesday posts, which will switch to every other week.

The purpose of this series is to highlight articles that have changed recently, as well as to recognize the contributors who did the work. This doesn't include every change, just "significant" ones. Future posts may be a bit shorter, as they'll cover only the two weeks since the previous "state of the docs" post.

Web standards docs

Jean-Yves Perrier documented the <bdi> element. It allows inserting spans of text with unknown directionality, like text coming out of a database, in the middle of text with a known fixed directionality. He also updated the CSS unicode-bidi property to describe the two new values: isolate and plaintext, which are used to implement correctly bi-directionality for each HTML element (including, but not only, <bdi>, <bdo>, <pre> and <textarea>).

Jean-Yves rewrote the docs for the CSS property text-overflow, to account for the new extended two-value syntax and the new allowed string values, as well as adding new examples.

Jean-Yves also added pages for columns, updated column-width and column-count, and Using CSS multi-column layout.

Paul Irish made a rash of updates:

Kevin Lim continues to improve the IndexedDB docs:

fusionchess added a code example to Using files from web applications.

Aaron Leventhal updated the ARIA page with lots of doc and resource links, and wrote new articles on:

If you're interested in ARIA and accessibility, please help out with these docs. If you're not an expert, you can help identify where there are gaps, or things that don't make sense. Accessibility geeks might also be interested in the free-aria Google Group.

New pages!

Help wanted!

Want to write an article on CSS positioning? That is, how positioning properties for margins, padding, etc. work together. MDN does not have this topic covered yet. Or, if you've already written such an article, would you be willing to contribute it to MDN under a CC-BY-SA license?

Check out the MDN Getting started page. If you have questions, drop into #devmo IRC channel on irc.mozilla.org, or post to the dev.mdc discussion forum.

Mozilla-specific documentation

Henri Sivonen wrote about HTML parser threading in Gecko.

jbeatty improved Patching a localization, Create a new localization and several other localization-related pages.

Tom Schuster added to the SpiderMonkey JS API reference for:

Eric Shepherd wrote up complete reference docs for the new JavaScript Debugger API. However, the user guide for the Debugger API needs a lot of attention. We don't have any examples at this point. A sample add-on that uses the API should be written, but even the JSAPI team hasn't done one yet.

Firefox 8 was released on November 8, and Firefox 8 for developers is complete except for a few lower-priority items.

decoder created an article on Testing with Linux on ARM architecture using QEMU.

Jorge Villalobos updated several pages of the XUL School tutorial.

Eric Shepherd created an article for the Mozilla Developer Guide on Getting documentation updated.

09 Nov 2011 9:52pm GMT