…EADME in place to point to Apache
…int out error msg
When proxing an XMLHttpRequest call via the XHR proxy, the `jar` option in the `request` package was turned on by default. This would remember cookies for future requests, which is bad because each request should be separate, and the domain for cookies is the proxy's address, which is invalid, anyways. As a result, there ended up being a large accruing of random cookies that had buggy effects, such as hitting cookie header size limits on various web servers. This fixed GitHub Issue: http://github.com/blackberry/Ripple-UI/issues/732 Side Note: It seems cookie support, in general, is not feasible with the proxy enabled, because the remote domain is always the proxy's address, and not the actual remote domain being requested. This is something to figure out separately.
This updates the h1 font size to be smaller and relatively closer to other headers. Pointed out in GitHub Issue: https://github.com/blackberry/Ripple-UI/issues/698 Also, in the non RIM distribution, Ripple Services was still in an 'h2' tag, vs in an 'h1' tag (like in the RIM distro). This makes things the same.
This was pointed out in GitHub Issue: https://github.com/blackberry/Ripple-UI/issues/698
It makes sense to keep things up to date, following project updates. Legacy will still work at the moment, but not forever. * "globals" can be used instead of "prefdef" * there is no more "nomen" or "white" option * add "trailing" (whitespace) to cover for "white" option
Before, it seemed to not give full context to what a build target is,
This commit adds support for feature #686. All of the mobile-spec tests are now passing and unit tests cover most of the code. Most of the settings are via the device panel with some interesting workarounds: - no timezone support (just returns ??? for the timezone, we can fix this later if someone wants it) - DayLight savings time is handled via a checkbox in the device settings, if checked all dates are returned as isDST - All number and currency formatting is hardcoded to be North American. (can be controlled via the accountingjs if needed)
It did not cause any visible breakages in the Chrome Extension build target, but in the hosted version (where assets are loaded from `ripple/assets`) it shows up.
This build target is no longer (primarily) used, and now that there is a hosted build target, which can function without the chrome extension (i.e. standalone) this is no longer needed, and should be removed. This also cleans up some hacky (complexity inducing) code (such as the omnibar checks) that has never felt right.