(Bug 4771, 4780, and 4781) Upgrade jQuery / jQuery UI #179

merged 30 commits into from Dec 11, 2012


None yet
1 participant

afuna commented Dec 11, 2012

And adjust our JS for compatibility, and to take advantage of new
things from jQuery/jQuery UI.

afuna added some commits Oct 17, 2012

(Bug 4771) Update URLs for old js files in tests
Fixes tests before we update the jQuery libraries, so we know that we're
starting from a known good state
(Bug 4771) Fix test
The third parameter to error functions has changed from a simple string
to an instance of *Error object.

This fixes the test after updating to the latest libraries, but before
we make any changes to our JS files
(Bug 4771) Use namespaced widget names
"ui-autocomplete" vs "autocomplete"; "dw-cuttag" vs "cuttag" for forward
compatibility. The non-namespaced versions will be removed in a future
version of jQuery.
(Bug 4771) Update autocomplete to new API
Also fall back onto the standard implementation instead of having
redundant code trying to handle it on our own.
(Bug 4780) Switch over to using the new tooltip.js
Also includes switching over to a new API for ajaxtip, because we can
simplify some things.

Updated files which use ajaxtip for an error/status message
(Bug 4780) Update $.throbber usage
- The throbber will now always be placed after, never before.
- Changed the implementation to use a background image instead of
  appending an image, to keep the text from potentially bobbing up and
- use $.throbber from dw-core.js, instead of having multiple different
  implementations of handling the image
(Bug 4780) Close the tooltip if you hover over the tooltip itself
This case covers error messages which behave like so:

- if you click and quickly receive an error (while you're still over the
  trigger), then the error message fades away when you move your mouse
  away (or lose keyboard focus)

- if you clicked then moved away, maybe doing something else on the
  page, then the error message doesn't fade away to give you a chance to
  see it.
    - the error message will fade away if you interact with the trigger
    - the error message will fade away if you interact with the tooltip
    - in both cases, interaction can mean either a hover/leave, or
      keyboard interaction (if there's something focusable in the
(Bug 4780) Update commentmanage to use new tooltips
- instead of using a tooltip for a dynamic form (what was I
  thinking???), use a dialog. Immediate plusses are that we don't have
  to worry about keeping the tooltip persistent. May also help with
  screen reader accessibility because the role is now more semantically
  correct (dialog). Also keyboard accessibility...

- various tweaks in commentmanage

- use self.error instead of trying to use the content option's callback

- include new files. Limit scope of iconselector CSS so it doesn't
  affect other dialog boxes

- fix tests
(Bug 4780) Update the tracking JS to use dialog + new ajaxtip API
Also fixes the issue where the comment icon didn't update when
tracking a thread.

It was broken because we passed in the LJ_cmtinfo variable when creating
widgets (so we could access the cmtinfo as a local variable for slight
efficiency purposes). Problem was that the LJ_cmtinfo variable is
initialized after we create the widgets. So now we just use the global
variable, which isn't ideal but will do.
(Bug 4780) Pass in an array to "load" to handle multiple requests
Old method just plain didn't try to error-check if we said that the
ajaxtip should try to handle multiple simultaneous requests. Now we
handle it on a per-batch basis.

- Remove explicit option; instead handle it based on whether the options
  to be loaded is an object or an array of objects

- If we call load again on the same widget for a new batch of requests,
  we abort the old one and start again with the new

- Change the tracking widget to use the new API. Tracking widget needs
  it because each checkbox is a separate AJAX request.
(Bug 4780) Close all open tooltips when you click anywhere on the page
Only exception: if you clicked on the tooltip itself for some reason,
don't close it yet. (But will close once you move your mouse away from
(Bug 4780) Behavior for the contextual hover menu
The contextual hover menu

        - when you hover over the trigger a short period of time
        - NOT if you merely pass the mouse over the trigger

        - as long as the mouse is over the trigger
        - if you move the mouse from the trigger to the contextual popup
        - as long as the mouse is over the tooltip
        - NOT if you move the mouse away from the trigger before the
          popup is fully visible

        - when you move the mouse over then out of the contextual popup
        - a short time after you move the mouse out of the trigger
            (only if you don't then move it to the popup)
(Bug 4780) Don't show the loading throbber for contextualhover
Prevents the contextualhover trigger (user icon, userhead) from
wriggling when you mouse over them

Instead of the throbber, add "Loading..." text to indicate we're doing something

So that the popup with data doesn't just appear with no warning.

Not doing the standard throbber appear/disappear, because it was
wiggling icons / links out of place on hover (somewhat disturbingly so).
We might want to show the image instead of text (obv with alt text), but
let's start with text.
(Bug 4781) Customize Smoothness theme
- Reduce gloss on buttons / headers a tiny bit for increased contrast
- Change the pillowy gradient on dialog boxes, which doesn't fit any of
  the other elements on our site, to a flatter texture
- Reduce widgets font size from 1.1em to 1em -- that is, make the
  widgets the same size as the text on the rest of the page (which we
  keep at a reasonable size already), not startlingly larger
(Bug 4780) Style the tooltips / contextual hover menu
- reorders elements in the contextual hover menu and modifies class
- prevent inclusion of the old contextual hover css by adding the
  "default" group when including it
- various styling tweaks
(Bug 4771) Use .prop instead of .attr
.attr() is supposedly now for initial state, .prop() for current state.
Looks like jQuery has some backwards compatibility for this case. Don't
*need* to update, but updating anyway before one of the nuances comes
back to bite us.

This also means that we have made setting / checking the trueness of
diasbled/checked is more consistent throughout.

afuna added a commit that referenced this pull request Dec 11, 2012

Merge pull request #179 from afuna/jquery-update-bug4771
(Bug 4771, 4780, and 4781) Upgrade jQuery / jQuery UI

@afuna afuna merged commit 079c2fe into dreamwidth:develop Dec 11, 2012

@afuna afuna deleted the afuna:jquery-update-bug4771 branch Jun 20, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment