Custom Query (7259 matches)


Show under each result:

Results (121 - 123 of 7259)

Ticket Resolution Summary Owner Reporter
#6757 fixed .ui-widget :active { outline: none; } causes slowness in FF lukebrookhart

The following CSS class causes 1-3 second slowness with larger forms in FF.

.ui-widget :active { outline: none; }

Upon clicking a checkbox, there is a delay of 1-3 seconds before checkbox appears. Clicking a select dropdown delays the display of the dropdown by 1-3 seconds as well.

My test form has 1873 form elements (mostly checkboxes via a city and town selections, but it does include selects and inputs)

#5185 fixed .ui-widget-overlay CSS selector causes consistent large memory leak in IE Rwhitbeck

The jQUI CSS selector .ui-widget-overlay when used to display the blocking overlay when a widget (in my case the dialog) uses about 11mb of ram every time I open a dialog between page refreshes.

An example of the rule from the trontastic theme (in the file jquery-ui-1.7.2.custom.css) looks like this: Copy code

  1. .ui-widget-overlay { background: #5c5c5c url(images/ui-bg_flat_50_5c5c5c_40x100.png) 50% 50% repeat-x; opacity: .80;filter:Alpha(Opacity=80); }

I have to comment this out and rewrite it as follows with no filter:Aplha(Opacity) and using a 1px x 1px transparent PNG to perform my blocking stops the memory leaks in IE, but I lose the opacity:

Copy code

  1. .ui-widget-overlay { background: url(/appui/images/overlay.png) 50% 50% repeat-x; }

This is happening in ASP.NET apps that I am writing, if that makes any difference. I assume it would also occur if I used any other selectors that use the opacity filter as well but have not tested this yet.

Please help: I would really like to use the opacity and have a nice overlay but I do have to support IE as well as all other A grade browsers.

See Forum:

#7339 notabug /focusout/ (or /blur/) should not be issued when user picks from the list ekkis

I want to make a case for having this plugin make sure that no /focusout/ or /blur/ events are generated for the textbox when the user makes a selection from the selection list. the argument is that from a functional perspective, the user is not really leaving the textbox, he's merely supplementing his current entry into the textbox by using an extension to the textbox.

firing these events is problematic. consider the following situation: you want to insert the user's entry into a database only when said entry was NOT picked from the list (this would make sense because the data entered obviously does not exist in the database). the insertion would be made on the /blur/ event of the textbox, since that signifies that the user is done with his entry. if no /select/ event was fired, the entry does not exist in the db, otherwise it does.

Now consider that if the textbox receives a /blur/ event when the user goes to make a selection from the list, we have no way of distinguishing between the user being done with his entry, and his continuing to enter data!

from my perspective, issuing the /blur/ is of no value but not issuing it is very valuable indeed.

Incidentally, this ticket is related to #5928, which I could not reopen. Also created # 7336, which can be closed as this supplants it (I can't seem to close it).

Note: See TracQuery for help on using queries.