This patch creates a new MOZ_FRAMEPTR_FLAGS variable that is used only to
control the frame pointer flags passed to the compiler. It also computes this
flag in a macro so that the toplevel configure and js/src/configure stay in
sync.
--HG--
extra : rebase_source : 58a64b71a23812910072c81bbf84b3721b961abb
There was actually some surrounding logic breaking 0-size textures. It was because there was code that basically checked "did uint=negative_num*other_vars overflow". For incorrect validation, two copies of the same variable (one stored internally and one passed in) were available to the function, but the one stored internally was being validated, while the version passed in wasn't. The fix for this was simply checking the passed var instead.
The bindX() commands were erroring with INVALID_VALUE when they're instead supposed to simply fail silently when they're given a deleted object. Additionally, the getParameter() function was failing after its associated variable was deleted, sometimes returning values when it should return null.
* * *
Bug 681835: WebGL fix for previous patch which introduced a bug with deletion
DeleteRenderbuffer and DeleteFramebuffer weren't checking if the deleted buffer was the currently bound buffer before deleting them. This patch implements this functionality. A separate test case patch was also submitted to Khronos:
http://www.khronos.org/bugzilla/show_bug.cgi?id=518
Manage private browsing mode in content pref service. CPS should be available
in private browsing mode, but should not store informations on disk, and should
clear all informations once the private session ends.
When setting a pref in private mode, it is stored in an in-memory hash table.
When getting a pref, it is retrieved from that hash table if available.
Otherwise, it is retrieved using the standard mechanism. When removing a pref,
it is retrieved from the hash table. The rationale is that in private mode,
it's ok to read a pref from normal database, but not ok to set it.
The in-memory hash table is cleared when leaving the private browsing mode.
When removing a set of preferences (with removeGroupedPrefs or
removePrefsByName), preferences are removed from the in-memory hashtable, *and*
from normal mode database. The rationale is that visiting a website may trigger
setting/getting/removing for a specific preference only. But removing many
prefs at once is the result of an action not associated with a website. For
example, user may wish to delete all its informations. In that case, user
probably expects to not have those informations restored once it leaves private
browsing mode.
