lands

New Responsive Design Mode: RDM Lands in Firefox Dev Tools

Firefox Developer Tools now includes a completely redesigned Responsive Design Mode (RDM for short) that’s just landed in Firefox Developer Edition, thanks to hard work from the DevTools team.

In a mobile-first world, it’s essential to prioritize performance for low-bandwidth and offline mobile experiences and design progressive web apps that can deliver across a range of devices. We aim to design developer tools that prioritize empathy for users and developers. That’s why we’ve put so much effort into the Responsive Design Mode.

We want to make it easier for developers to build web experiences that load and respond on screens of all different sizes and support a multitude of browsers, platforms, and device types. RDM is a significant upgrade to the Firefox tools themselves, reflecting our commitment to people who build for the web.

To access the RDM tool, make sure you’re running an up-to-date version of DevEdition. Next, open any web page to view  the Responsive Design Mode via Developer ? Responsive Design Mode.

There’s a lot in this new tool, and many new features still to come. Check out the video walk-through to see the tool in action with all of its features enumerated, including:

  • Popular device emulation
  • Network throttling
  • Touch-event emulation
  • Ability to set DPR (device pixel ratio) of devices
  • Screenshotting devices at certain sizes

Firefox Developer Tools already has a series of improvements planned for the next release of Responsive Design Mode, including:

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

WebIDE Lands in Nightly

Editor’s note for the impatient: if you want to help test it on a recent nightly you can toggle the devtools.webide.enabled preference in about:config. The WebIDE is available today under Tools>Web Developer>App Manager and will be renamed in tomorrow’s Nightly into WebIDE.

If you’ve been following our Developer Tools series on the Mozilla Hacks blog, you’ve seen the developer tools evolve from pure inspection to a debugging environment both for web sites and apps on desktop and mobile. Today we want to introduce you to the next step of evolution: adding in-browser editing features across devices.

WebIDE

Developers tell us that they are not sure how to start app development on the Web, with so many different tools and templates that they need to download from a variety of different sources. We’re solving that problem with WebIDE, built directly into Firefox. Instead of starting from zero we provide you with a functioning blueprint app with the click of a button. You then have all the tools you need to start creating your own app based on a solid foundation. WebIDE helps you create, edit, and test a new Web application right from your browser. It lets you install and test apps on Firefox OS devices and simulators and integrates the Firefox Developer Tools for seamless debugging and inspection across those devices. This is a first step towards debugging across various platforms and devices over WiFi using open remote debugging APIs.

Readability app open in WebIDE

Getting Started

After opening WebIDE you start creating your new application with a few clicks. You choose from a set of example starter templates – and we’re working with the community to build a wide variety of additional examples. You can help creating templates by visiting https://github.com/mozilla/mortar.

Editing

Once you’ve started your project, you can edit the source files in WebIDE. Its integrated editor – based on the open source CodeMirror editor with the tern.js code analysis framework – gives you a simple but powerful editor for HTML, JavaScript, and CSS files.

Editing in WebIDE

While working with your web application manifest, the application validator will help you find common problems before submitting to the marketplace.

While this is enough for your basic editing needs, you might want to use your own preferred editor instead. To do this you can use a simple API which allows external editors to access all the advanced functionality of the tool – its runtime management, pushing applications to different devices and connecting Firefox Developer Tools. You can turn off our internal editor and leave WebIDE with a simple, clean interface for managing runtimes and validating applications. We want to make it easy for users of any code editor to sling their code around to various devices.

Packaged App Demo in WebIDE

Runtimes and Testing

When you’re ready to test your application, choose a runtime – we’ll install Firefox OS simulators for you or help you connect to your Firefox OS device. Once connected to a runtime, you can use the tools that you’re used to in desktop Firefox to try your application. You have the same sort of rapid iteration that makes developing for the desktop web simple – just hit Ctrl/Command+R to reload the application on your device or simulator. You can get information about the device and runtime and take screenshots.

Take a Look

You can see the WebIDE in action in this screencast

While we put on some finishing touches, WebIDE is checked into Firefox Nightly but is hiding behind a pref – if you want to help test it on a recent nightly you can toggle the devtools.webide.enabled preference in about:config:

Enabling WebIDE in Firefox Nightly

The Future: Developing for the Whole Web

At the heart of the WebIDE is the Firefox Remote Debugging Protocol. The Firefox Developer Tools team has put a lot of work into making sure all of our tools work on remote devices running over USB, but that’s really only the beginning. With WebIDE managing these connections we can use the Firefox Developer Tools – and any other tools that want to use our protocol – anywhere.

Right now this protocol is useful for Firefox Desktop, Firefox Android, and Firefox OS. But we aren’t stopping there. We’re working on a protocol adapter that will allow clients using the Firefox Remote Debugging Protocol – including the Developer Tools and WebIDE – talk to all mobile browsers, regardless of rendering engine or runtime. Our first targets are Chrome for Android and Safari on iOS.

This web-everywhere project isn’t yet ready for testing, but if you’re excited to get involved or see how it is being implemented, it currently lives at https://github.com/campd/fxdt-adapters.

If you’re building a tool and want to start playing with the protocol you can start now, developing against Firefox Desktop, Firefox Android, and Firefox OS. For information about the Remote Debugging Protocol, take a look at the documentation.

Thanks for reading. We look forward to hearing your feedback in the comments, on our UserVoice feedback channel and on Twitter @firefoxdevtools.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Content Security Policy 1.0 lands in Firefox Aurora

The information in this article is based on work together with Ian Melven, Kailas Patil and Tanvi Vyas.

We have just landed support for the Content Security Policy (CSP) 1.0
specification
in Firefox Aurora (Firefox 23), available as of tomorrow (May 30th). CSP is a security mechanism that aims to protect a website against content injection attacks by providing a whitelist of known-good domain names to accept JavaScript (and other content) from. CSP does this by sending a Content-Security-Policy header with the document it protects (yes, we lost the X prefix with the 1.0 version of the spec).

To effectively protect against XSS, a few JavaScript features have to be
disabled:

  • All inline JavaScript is disallowed. This means, that all the JavaScript code must be placed in a separate file that is linked via <script src=... >
  • All calls to functions which allow JavaScript code being executed from strings (e.g., eval) are disabled

CSP now more intuitive and consistent

While Firefox has had support for CSP since its invention here at Mozilla, things have been changing a lot. The streamlined development of a specification within the W3C has made the concept more intuitive and consistent. Most directives in a CSP header are now of a unified form which explicitly specifies the type of content you want to restrict:

  • img-src
  • object-src
  • script-src
  • style-src and so on.

Oh and if you feel like you must allow less secure JavaScript coding styles, you can add the values unsafe-inline or unsafe-eval to your list of script sources. (This used to be inline-script and eval-script before).

Start protecting your website by implementing CSP now!

But wait – isn’t that a bit tedious… Writing a complex policy and making sure that you remembered all the resources that your website requires? Don’t fret! Here comes UserCSP again!

Generate your Content Security Policies with UserCSP!

During the last few months, Kailas Patil, a student in our Security Mentorship Program has continued his GSoC work from last
year
to update UserCSP.

UserCSP is a Firefox add-on that helps web developers and security-minded users use CSP. Web developers can create a Content Security Policy (CSP) for their site by using UserCSP’s infer CSP feature. This feature can list required resource URLs and turn them into a policy ready to plug into a CSP header.

In addition, UserCSP is the first step to expose a policy enforcement mechanism directly to web users. Furthermore, users can enforce a stricter policy than a page supplies through the add-on or apply a policy to certain websites that don’t currently support CSP.

While earlier versions of UserCSP were more aligned to content security policies as originally invented at Mozilla, this version is updated to be in compliance with the CSP 1.0 specification. This means that policies derived with this add-on may work in all browsers as soon as they support the specification. Hooray!

As this evolves and ships, our MDN documentation on Content Security Policy (CSP) will keep on evolving, and we also plan to write more about this in the Mozilla Security Blog in the next few weeks, so stay tuned!

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Firefox OS support lands in EnyoJS 2.2

Originally the app framework for HP webOS, the Enyo framework has since evolved into a full-featured cross-platform cross-device HTML5 framework for the modern web developer. Following the philosophy of reusing code and rapid quality development, Enyo uses an object-oriented encapsulation model, where you build components you can move around, extend upon, and reuse in a modular manner. Hiding the messy platform-specific quirks, if you code an Enyo app once, it’ll work the same in Internet Explorer, Firefox, Google Chrome, iOS, Android, etc. Now, with its latest v2.2 stable release it extended its list of supported platforms to include Windows 8, Windows Phone 8, BlackBerry 10, and yes, Firefox OS!

Introduction video/talk to what Enyo is.

Back in January, I had the pleasure of attending one of the Firefox OS developer workshop events. After testing out Enyo on Firefox OS devices, a few issues were discovered, which I’m happy to say have since been fixed by my recent pull requests to Enyo’s open source repository. So if you’re wanting to use Enyo to create new apps, or even use existing Enyo apps on Firefox OS, below are a few things to keep in mind.

Platform Detection

As much as much as Enyo aims to be platform-agnostic, sometimes you just need to know what you’re running on. The enyo.platform JavaScript object is here to help in that regard. As a side benefit of the changes I made, if you’re running on Firefox OS, you get the enyo.platform.firefoxOS property, which returns the OS version number (undefined property on other platforms). Thanks to this, you can do conditional changes and features just for Firefox OS:

if(enyo.platform.firefoxOS) {
    //do super awesome Firefox OS-specific feature
}

The :active:hover Selector Workaround

Whenever a button or control in Enyo is pressed, it simply uses the “:active:hover” to change the styling and look in a pressed-state. However, Firefox OS doesn’t support this out of the philosophy that a finger is not a mouse (at least that’s how it was explained to me). After trying out a few potential workarounds, the easiest solution is by using events to fill in the gap.

The Enyo framework makes itself platform-independent by not only harnessing standard and custom browser events, but also by normalizing, and if necessary, synthesizing events into a standard predictable set of events that then occur on every device. These events include:

  • down
  • up
  • tap
  • move
  • enter
  • leave
  • hold
  • release
  • holdpulse
  • flick
  • dragstart
  • drag
  • dragfinish
  • drop
  • dragover
  • dragout

There are a variety of ways to approach the problem, but for simplicity’s sake, it’s easy to focus on the down and leave events. The down event is whenever the mouse clicks down, or a finger touches down on a control, whereas the leave event is when the mouse/finger moves off of the control. We can use the down event to apply a CSS class, then the leave event to remove the styling.

So let’s say, for example, we want to have some text highlighted when clicked/tapped. We could make a “Highlightable” control in the following fashion:

enyo.kind({
    name: "Highlightable",
    classes:"hl-text"
});

And define the CSS as:

.hl-text:active:hover {
    background-color:yellow;
}

And then use the “Hightlightable” kind like this:

enyo.kind({
    name: "App",
    components: [
        {
            kind:"Highlightable", 
            content:"This is a simple example of text that highlights when clicked/tapped on."
        }
    ]
});
new App().renderInto(document.body);

Now to enact our workaround for Firefox OS, we can modify the CSS to:

.hl-text.pressed, .hl-text:active:hover {
    background-color:yellow;
}

From here, it’s a simple matter of adding and removing the pressed class on the events. We can use enyo.platform.firefoxOS to only apply the styling as needed. One little hitch: the Firefox OS simulator does in fact support :active:hover CSS selectors, as the mouse is in-use. Thankfully, we can further filter out the simulator from getting pressed styling applied by checking the value of the srcEvent.type property of the event data. The end result gets us this:

enyo.kind({
    name: "Highlightable",
    handlers: {
        ondown: "highlight",
        onleave: "unhighlight"
    },
    classes:"hl-text",
    highlight: function(inSender, inEvent) {
        if(enyo.platform.firefoxOS && inEvent.srcEvent.type !== "mousedown") {
            this.addClass("pressed");
        }
    },
    unhighlight: function(inSender, inEvent) {
        if(enyo.platform.firefoxOS && inEvent.srcEvent.type !== "mouseout") {
            this.removeClass("pressed");
        }
    }
});

An expanded working demo is available on jsFiddle:

WebAppInstaller and the WebAppButton Component

To make the process of creating Firefox OS, Firefox Marketplace, and Chrome Webstore apps easier for Enyo developers, the third-party WebAppInstaller library consolidates the various installation formats into a unified API with the ability to check if a webapp is installed and to install a hosted webapp. Furthermore, included in the library is an Enyo control called WebAppButton, which is an “Install” button that installs the current hosted webapp, and will either hide itself or turn into an “Update” button depending on the way you configure it.

To demo this functionality, there is an installable Enyo sampler webapp (source code on GitHub)

Enyo 2.2 framework is available free under the Apache 2.0 license at http://enyojs.com
WebAppInstaller is available free under the MIT license at https://github.com/JayCanuck/enyo-2-components/tree/master/webappinstaller

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)