I'm using the autocompletesearchparam as a vehicle for delivering the
privacy information into the guts of nsSearchSuggestions. The
alternative solution will involve modifying the autocomplete interfaces,
which is even more horrible than what the code here does. It's not that
bad if you think of autocompletesearchparam attribute as an opaque value
which is used to transfer information to the nsIAutoCompleteSearch
implementations, which is what it is!
--HG--
extra : transplant_source : %B3%9B%C1%F5%E0%F8%BCD%F4%3CY%D7%AF%27%3E%05%99%28%A5%C6
This is required when a channel with an overridden privacy status (such as
a favicon HTTP load channel) gets redirected, for example.
--HG--
extra : transplant_source : %00%7EE%A1%F6%C9%B0%5BR%EA%3E%93%7C%1B%AA%5D%D6K%88%C7
This adds a new FX_TAB_SWITCH_TOTAL_MS that should more accurately represent
the user experience of tab switch time than FX_TAB_SWITCH_UPDATE_MS.
FX_TAB_SWITCH_UPDATE_MS is being kept because it gives a good indication of how
much time is being spent in the front end parts vs the painting parts.
This works by measuring the time between beginTabSwitch() and the first call to
LayerManager::PostPresent().
--HG--
extra : rebase_source : 8c5163398489de3b2222665ed48297b6eb6cf722
Updating plugin widget geometry every time we paint means we don't have to
explicitly request plugin geometry updates.
This patch stops us from flushing plugin geometry changes in
FlushPendingNotifications(Flush_Layout). There are too many Flush_Layouts and
flushing plugin geometry changes on them produces frequent
desynchronization of the plugin geometry with the rendered window contents.
There is some Web compatibility risk there --- it means we have to change
our tests, for one thing --- but hopefully it's OK.
--HG--
extra : rebase_source : c20d0ce8e4934e053f8264ddda76a136617df8c6
The current code sets the plugin size to 0,0 and then does some stuff after a setTimeout(0), then
sets the size back to 1,1 and expects to be sure to get a new paint event. This is wrong since
the timing of plugin geometry changes isn't guaranteed, so we might simply not resize the plugin
between setting the size to 0,0 and 1,1.
--HG--
extra : rebase_source : 8c23a839b2ea62c4a354483d1f39868fb5a4f358
Updating plugin widget geometry every time we paint means we don't have to
explicitly request plugin geometry updates.
This patch stops us from flushing plugin geometry changes in
FlushPendingNotifications(Flush_Layout). There are too many Flush_Layouts and
flushing plugin geometry changes on them produces frequent
desynchronization of the plugin geometry with the rendered window contents.
There is some Web compatibility risk there --- it means we have to change
our tests, for one thing --- but hopefully it's OK.
The current code sets the plugin size to 0,0 and then does some stuff after a setTimeout(0), then
sets the size back to 1,1 and expects to be sure to get a new paint event. This is wrong since
the timing of plugin geometry changes isn't guaranteed, so we might simply not resize the plugin
between setting the size to 0,0 and 1,1.