Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#9686 closed bug (worksforme)

Resizeable UI causes page reload

Reported by: emmett Owned by: emmett
Priority: minor Milestone: none
Component: ui.resizable Version: 1.10.3
Keywords: Cc:
Blocked by: Blocking:


I am using the jQuery UI resizeable on a page and I find that the page is reloaded once whenever the following code is in the page:

        resize: function(e, ui) {
        handles: 'all',
        stop: function(e, ui) {
          $.get ('fill-slide.php', { sid: 1259, attr: 'sz', container: 'fr_blk_0', width: ui.size.width , height: ui.size.height });

There is a lot of jQuery code in this page, including dragable and dialog, but there is never a page reload unless the above code is in the page.

I am using jQuery 2.0.3 and UI 1.10.3

This page can have multiple emements that are resizable and dragable, yet the page reloads only once.

I first saw the problem when I passed GET variables that would cause a new element to be added to the page. The second page reload would cause the new element to be created again as the reload included the full URI of the original request.

It occurs like there is a PHP header('Location:') call after the page loads once. Using LiveHTTPheaders I can see that the page is requested twice, but only when the jQuery resizable code is present.

I even tried it with only the resizeable code (no other javascript except the jquery and ui js files), both inside $().ready() and just before the closing </body> tag. In both cases the page was reloaded.

If I take away the resizeable code (above) there is no page reload.

This happens in both Firefox and Chrome.

Change History (12)

comment:1 Changed 9 years ago by Scott González

Owner: set to emmett
Status: newpending

This sounds like it's a result of the Ajax call, not a result of the resizable code.

comment:2 Changed 9 years ago by emmett

Status: pendingnew

There are no ajax call in the code. I created a jsFiddle at

Though I don't know how you are going to tell that it is getting loaded twice. However you can also see it at

If you load the page with ?resize=1 then the resizable element will be loaded, otherwise only the draggable element will be loaded. And... I still don't know how you will be able to tell that the page is getting reloaded. I suppose you'll have to get the source and run it on your own server and note in your log that it reloads only when resizable is enabled.

I supose the next thing to do is trace the resizeable code with firebug.

comment:3 Changed 9 years ago by Scott González

Status: newpending

When do you think the page is reloading? Immediately? After the resize?

Even on your hosted page, I'm only seeing the alert that the page loaded once.

comment:4 Changed 9 years ago by emmett

Status: pendingnew

There are two calls to the page when looking at the apache access log. Also there is some server sode code that print to the log that that the code was entered twice. Plus, before I added code to redirect to the page wirhout the "add element" GET variables, a duplicate element would get added on the page reload. So that each time I added a single element a second element would also be created.

I am not seeing the duplicate elements now, but it bugs me that there is an unnecessary second page load and I'd like to know why and how that is happening.

And I did notice that the javascript that does the "page loaded" alert is not executed on the unnecessary page reload. And that is even more curious.

As for when... If I put a client side delay inside the $().ready() function, the apache log and the server side code shows that the second page load happens as a result of entering that function. And it only happens when the resizable UI element is present in that function.

Plus it doesn't matter if it is after the resizable initialization or before. So I don't belive it is the resizable code that is causing the page reload. Of course that may not be so as the sleep function cannot be asynchronous, and so if the resizable code was doing something asynchronously then the sellp may happen before any action is taken by the resizable code.

I'll keep trying to think up new ways to debug and add comments if I do find something else to comment on.

comment:5 Changed 9 years ago by Scott González

Status: newpending

Until there is a way to debug this with just jQuery UI code, there's not really anything we can do.

comment:6 Changed 9 years ago by emmett

Status: pendingnew

The page at is all jQuery UI code. I'd be happy to provide the source that includes PHP code that shows the reload in the apache error_log. Plus yu can see it in firbug and chrome.

Add ?resize to cause the resizable initialization.

There is something new I discovered today. In both firefox/firebug and Chrome, you can see that when the second load happens javascript is not loaded. In firefox you can see it easier because the current version of firebug is so slow that you can see that upon the first load the javascript shows in the panel, then a second or two later it disappears.

This is why your are not seeing the second 'page loaded' alert.

In the firefox panel the following messages shows after the page reload:

Reload the page to get source for:

That makes it impossible to debug.

With the ?resize parameter the page loads twice and once without. The resize parameter causes the resizable code to get initialized. Note that even though it gets reloaded, the resizable code works and the block is resizeable.

I suppose I'll try an earlier version of the UI code next to see if that makes a difference.

comment:7 Changed 9 years ago by Scott González

Status: newopen

There is still a lot of code on that page. You need to do a few things before we can really look into this.

  • Use a doctype that triggers standards mode.
  • Don't mix versions between CSS and JS.
  • Remove everything not related to initializing a resizable (including the alerts).

comment:8 Changed 9 years ago by Scott González

Status: openpending

comment:9 Changed 9 years ago by emmett

Status: pendingnew

I trimmed out all code unnecsssary to demonstrate the issue. Changed the DTD XHTML 1.O Strict and verified that the code validates with no errors or warnings. (

I also changed all jQuery library load to user the same versions, including the CSS link.

The issue remains. One note, I have changed my PHP code to mitigate the second load, so my system is working. However, the problem of not being able to debug javascript is still a major problem. That and the fact that an autonomous and unexpected page reload indicates a problem in the core jQuery code and I'd like to help get it resolved.

comment:10 Changed 9 years ago by Scott González

Resolution: worksforme
Status: newclosed

I copy and pasted your page into a file on my computer, put the file in a directory serviced by Apache, and this is the entirely of the access log when opening that page: - - [06/Dec/2013:13:15:56 -0500] "GET /demos/resizable/default.html HTTP/1.1" 200 4182

I don't know what else to tell you. It doesn't even make sense that resizable can cause a page reload.

comment:11 Changed 9 years ago by Scott González

Sorry, forgot to include the flag (this is why I asked you to actually reduce your page).

Here's the log with the query parameter: - - [06/Dec/2013:13:18:21 -0500] "GET /demos/resizable/default.html?resize HTTP/1.1" 200 4182

comment:12 Changed 9 years ago by emmett

I found the cause of the page reload. It was the CSS statement:

.ui-icon-gripsmall-diagonal-se { background-image: url(); }

If I remove that line, or change it to:

.ui-icon-gripsmall-diagonal-se { background-image: none; }

There is no page reload. So now that I see the cause I can assume that the browser's CSS engine is loading "this page" when the value for backgroung-image is empty. So it has nothing to do with resizable.

I remember that I used url() in an attempt to hide or remove the corner grip icon, and when it didn't show up after adding that statement I didn't look further.

Well, it was a good exercise for me, though do I apologize for taking your time. Thanks for being so responsive.

Note: See TracTickets for help on using tickets.