Student couldn't able to submit his answer in ie9
becuase mathjax was used before its complete loading
thats cuase the problem. Mathjax operations should be
handled synchronously inorder to avoid error.
BLD-1199
Also, removed the client-side analytics for logging in.
Ensures that analytics are collected for third-party-auth logins.
Fixed failing tests related to third-party-auth.
- fixed issue in Firefox where the init gets called multiple times
- fixed spacing issues and added more comments
- fixed indentation, added missing parens in comment, and fixed typo
Annotation Tools: Added lots of comments, fixed spacing, fixed slice issue
Annotation Tools: i18n fixed for this tool
- fixed Translator to Translators
Annotation Tools: Removed unnecessary class and worked with element object
The same bug in studio was fixed in #3893, and as TinyMCE is also used in LMS, it should be also fixed in LMS.
Here a common javascript file called 'ie_shim.js' is added, so that in the future it can be used for other IE compatibility purposes too.
Declare variables locally
- The `allSections` variable was leaking into the global scope, due to a
typo in the declaration.
- `dataProcessed` can be declared more narrowly within the callback.
Clean up fixtures automatically between tests
- Nesting test fixture markup within a DIV allows Jasmine to
automatically restore the fixture to a clean state between each test
run.
Fix id attribute collision typo
- This looks like a copy/pasta gone wrong; the two test INPUT elements
were both declared with the same id, `input_1`.
Remove trailing whitespace
The behavior previously tested here was to check that if a JSInput
element was marked as not processed, re-walking the DOM *should* have
reinitialized it. Unfortunately, this behavior is not supported by the
underlying JSChannel library. In fact, if JSChannel detects an existing
channel with the same origin and scope, it throws an uncaught exception,
leaving the DOM in a "broken" state.
JSInput will prevent duplicates from being added, as long as we don't
manually update the `data-processed` attribute. This behavior is already
being tested.
Select DOM elements with wildcard syntax
- DOM lookups were being done with non-existent literal selectors, so it
was returning empty lists. As assertions were to be made while
iterating over the list of elements, nothing was actually being
verified.
- Common code has been centralized in the setup function. By declaring
CSS selectors once, we minimize the odds of inadvertently using the
wrong selector, as happened here.
- Had these tests actually been iterating over a non-empty list, this
would have thrown undefined exceptions. jQuery.each calls its handler
with an index and an item/object as the arguments. However, the object
is a DOM-object, not a jQuery-object. These tests break, as they had
assumed the latter.
This test currently fails, meaning that the existing tests weren't
testing what they claimed.
Assertions are made for each element returned by the CSS selectors.
However, the selectors are assumed to be wildcard matches, but are
actually literal selectors. As there are no matched elements, this
causes the assertions to be (silently) checked zero times, without
failure.
