Place phoneId binding in a proper HTML node
The code where the phoneId binding in the phone-detail.html template is first explained in step 7
of the tutorial doesn't make it a child of a proper HTML node, which makes the end-to-end test
against the view (also introduced in step 7) fail.
The test acquires the binding right from the view (by.binding('phoneId')), and apparently this
operation fails when the binding is not a child of an HTML node, and therefore the entire test also
fails. As soon as the binding is placed inside a <span></span> tag pair, the binding is found and
the test passes. The code on github for step 7 has it right, the binding is within the span tags,
but in the documentation I'm patching here the span's are missing.
☆.。.：*・゜☆ MERCI ☆.。.：*・゜☆
It was confusing to read "end 2 end" as a numeric two. I kept wondering what two end(s).
Later in the tutorial, the text switched to "End to End" which made more sense than numeric two.
In firefox the version picker's dropdown icon from the default `select` element
is still showing. This CSS forces FF to hide the ugly default.
Closes#6878
When the search input box was submitted (i.e. by pressing enter) the
app was supposed to take you to the first item but this was not happening.
It turns out the app was just reading the wrong property for the path to
the item.
Closes#3078
With the minimum search length set to 3, it was not possible to search for `$q`.
Changing this to 2 fixes that without really upsetting the search display, since we
only display the first 40 API and 14 non-API items anyway.
Closes#3078
There are some files in the examples that look like JSON and the default
$http transformResponse handler was trying to convert these from strings
to object. An example was the style.css file in the
https://docs.angularjs.org/api/ng/type/ngModel.NgModelController docs.
This commit fixes this by simply removing this transform when loading
these files.
The previous solution for opening Plunkers from the docs relied on tight
coupling between the docs site and the plunkr site, in particular the
URL to the example code on the docs server was hard coded in the Plunker
site.
This change goes back to the old POST method of creating a Plunker, but
with a subtle difference: In the very old docs, the content was injected
directly into the example HTML at build time. This was easy enough to
do as the example actually ran in the current page but also increased
the size of the doc page.
The new examples are run in completely separate iframes. This new version
of showing a Plunker loads the file content for the Plunker from the
server by accessing the example's manifest.json file using $http requests.
This also has the additional benefit that you can now generate plunkers
from examples that are running locally or, frankly, in any folder on any
server, such as personal builds on the Jenkins CI server.
Closes#7186Closes#7198
