NTLMv2 is the default.
This adds a new preference:
network.ntlm.force-generic-ntlm-v1
This is to allow use of NTLMv1 in case issues are found in the NTLMv2
handler, or when contacting a server or backing DC that does not
support NTLMv2 for any reason.
To support this, we also:
- Revert "Bug 1030426 - network.negotiate-auth.allow-insecure-ntlm-v1-https allows sending NTLMv1 credentials in plain to HTTP proxies, r=mcmanus"
- Revert "Bug 1023748 - Allow NTLMv1 over SSL/TLS by default, r=jduell"
- Remove LM code from internal NTLM handler
The LM response should essentially never be sent, the last practical
use case was CIFS connections to Windows 9X, I have never seen a web
server that could only do LM
It is removed before the NTLMv2 work is done so as to avoid having 3
possible states here (LM, NTLM, NTLMv2) to control via preferences.
Developed with Garming Sam <garming@catalyst.net.nz>
In the future we will want to specifically just update source content without
necessarily triggering any other actions that might take place on a tick (like
queuing events).
Currently selectTreeItem, as used by various devtools storage panel tests,
expands the tree then clicks items. However, it fails to account for the fact
that expansion animations may mean that the item that should be selected is not
yet able to be clicked. It currently happens to be lucky enough that typically
the animation is short enough that the item in question will be click-able in
time (since click() spins the event loop using executeSoon there is some time
for the animation to play).
If we make animations wait until their first frame has rendered before
beginning the chance that the tree item will become clickable in time is
reduced. This patch works around that by looking for animating branches
amongst the ancestors of the item to be selected. If one is found it waits for
the animation to end.
Unfortunately this ties the tests to the tree widget styles somewhat (in
particular the test looks for specified values of max-height).
However, these changes only delay the execution of the test so, if these styles
were to change, it is only likely that these tests would fail (and hence need to
be updated) than to mask a genuine bug. Until the Web Animations API is
available by default it is difficult to test if animations are running so this
seems like the best we can do for now.
Currently many tests rely on nsDOMWindowUtils::AdvanceTimeAndRefresh. These
tests assume that the animation starts from the moment it is created. In order
to allow these tests to continue to operate without change we make
AdvanceTimeAndRefresh force any pending animations to start.
test_popupreflows.xul currently expects to get 1 reflow when a popup is opened.
This is triggered by JS code. An incremental layout may be triggered by native
code but the test ignores that for unclear reasons ("Because we've simply
cargo-culted this test from browser_tabopen_reflows.js!").
In part 16 on this patch series, we force interruptible reflows to become
full reflows when we have pending animations which can cause this test to
fail since it will see 2 reflows.
The above quoted browser_tabopen_reflows.js specifically ignores reflows
triggered by native code so we adjust this test to do likewise.
We want to time animations from when their first frame is painted. However,
interruptible reflow complicates this since, for a given set of pending
animations, some may be painted whilst others are not. To simplify this we
simply force an uninterruptible reflow when we have animations that are
waiting to start.
We would like to trigger animations from the point when the first frame of the
animation is painted. However, some animations will never trigger a paint (e.g.
animations with an empty keyframes rule). These animations should start start
however. To ensure this, whenever an animation is newly pending we schedule
a paint.
This patch adds a reference from PendingPlayerTracker back to the document
object that owns it. This is used in the next patch in this series to find the
document's root frame for scheduling a paint.
Normally animation players get times from their timeline which is based on the
refresh driver for their associated document. However, for animations that
we time from when their first frame has been rendered, we want to record the
actual time when painting finished as their start time. If we wait until the
next refresh driver tick then the delay between playing an animation and its
actual start will be too great.
In this patch, we introduce a mechanism for fast-forwarding a timeline to a
time between the current refresh driver time and the next refresh driver tick.
By adjusting the timeline rather than the player we maintain a consistent state
(in fact, if we just naively set the animation player start time to the
timestamp value we recorded when painting finished it will appear to start in
the future and the animation will temporarily jump from playing, to waiting to
start, then back to playing again on the next refresh driver tick).
To be completely consistent, however, when we fast-forward the timeline we
should tell all animation players listening to the timeline to mark their
target element as needing a style flush. Otherwise we may be able to observe an
inconsistency between some animation players' current time and the computed
style of their targets.
We don't, however, currently know which players are observing a given timeline.
We will likely introduce that in the near future (in order to implement
AnimationTimeline.getAnimationPlayers) and fix the inconsistency in timing then.
A test later in the patch series verifies this inconsistency so it is easy to
fix in future.
An alternative approach would be to simply record the time when animation should
start, send that time to the compositor but don't actually update the animation
start time on the main thread until the subsequent refresh driver tick. Such
an approach is complex as it introduces an additional state--"finished pending
but not yet started". We will attempt to switch to that approach in bug 1112480.
Note that this requires making sure that IsNaN is constexpr because it
needs to be passed to the constexpr IMPL_TO_JSVALUE() function in
DOUBLE_TO_JSVAL().
--HG--
extra : amend_source : dbd8bb0659b53e7d36d2600ac97f0a753ef772c7
