hared TooltipDialog loading different size remote content positions smaller content wrong

[Arlo White]

I've created some TooltipDialogs? attached to DropDownButtons?. In our application the TooltipDialog? positions wrong when you open a popup in one area and then in a second area. Re-opening the second popup positions correctly.

Live DEMO, steps to reproduce:

1. ​http://passdev.calpoly.edu
2. On left, click "Show Classes by Subject"
3. Select a department and then select a few classes
4. Click Next button in top-right
5. Click a link in the BOOKS column (Popup displays)
6. Scroll down to the next course and click a link

• Popup will often be positioned wrong initially
• Re-opening will position correctly

Notes:

• This issue doesn't always occur and the offset changes. For example, select BIO 111,112,114,115
  • Clicking between:
    • BIO 111 and BIO 112 > No issue
    • BIO 111 > BIO 114 > Problem
  • Individual rows can be different
    • BIO 114-01 to BIO 115-02 > No issue
    • BIO 114-01 to BIO 115-03 > Problem

• Something about opening a popup above and then another below in another course causes this. Going from a lower link to a higher one doesn't seem to be a problem. If you just reload the page and open the exact same link that had the problem it displays fine. Something about the state of the previous popup causes this.

• It's always the first positioning that's off, reopening always seems to position correctly. Though on a related note, without DropDownButton?'s popups were even worse and gradually migrated to where they should be as you re-opened the same popup.

• Scrolling doesn't seem to be the issue. If you click in an upper course and then back in the lower without scrolling the issue appears.

• I see this issue with Firefox 3.6.6 and Chrome 5.0.375.86 beta in Linux.

[bill]

Unfortunately you'll need to attach a self-contained test case using the attach file button. We can't debug based off of a "live demo".

[Arlo White]

DEMO illustrating popup positioning bug

[Arlo White]

Disregard a lot of my initial musings. In making the demo it became clear that the trigger is the size of the remote content being loaded into the popup.

This bug is probably exposed due to the fact that I'm sharing the TooltipDialog? among all of my DropDownButtons?. I extended DropDownButton? to change ioArgs before displaying the new popup. In the demo I swap the href between small and large content to reproduce the bug.

The bug seems to be caused by displaying a TooltipDialog? once and then redisplaying it farther down the page with smaller content. The position offset is probably the difference in heights of the content.

At this point I'm not sure if this is a bug or if I it's my fault for where I change the ioArgs/href parameters.

All of the relevant JavaScript? is in demo.html

Excerpt:

dojo.require("dijit.TooltipDialog");
dojo.require("dijit.form.DropDownButton");
dojo.require("dojo.parser");

dojo.ready(function(){

	dojo.declare("calpoly.PassBooksButton", dijit.form.DropDownButton, {
		sectionId:"",
		loadDropDown:function(){
			console.debug("loadDropDown()",this);
			this.dropDown.ioArgs.content.sectionId=this.sectionId;
			this.inherited(arguments);
		},
		openDropDown:function(){
			console.debug("openDropDown()",this);
			this.dropDown.ioArgs.content.sectionId=this.sectionId;

			// Dojo DEMO Code
			// Swap between big and small content so we can see the bug
			var dd = this.dropDown;
			var href = dd.attr('href');
			if(href=='books.do'){
				console.debug('setting href to books_small.do');
				dd.attr('href','books_small.do');
			}
			else{
				console.debug('setting href to books.do');
				dd.attr('href','books.do');
			}
			this.inherited(arguments);
		}
	});
	
	dojo.addClass(dojo.body(),'tundra');

	var tt = new dijit.TooltipDialog({id:'tooltipBookList',
			'class':'book-dialog',
			href:'books_small.do',
			title:'Class Book List',
			autofocus:false,
			preload:false,
			refreshOnShow:true,
			parseOnLoad:false,
			ioArgs:{content:{dispatch:'sectionList',sectionId:'DEFAULT'}}
		});
	//tt.startup();
	
	console.time('dojo parsing');
	dojo.parser.parse('main-content');
	console.timeEnd('dojo parsing');
});

[bill]

Sorry, what I meant was a small testcase, a single HTML file. You've attached 100 pages of code in a dozen files.

We haven't tried sharing a TooltipDialog between multiple buttons, so it's quite possible that doesn't work, but I'd need to see a small test case to debug it.

[Arlo White]

Smaller (minimal) DEMO of Bug

[Arlo White]

I've loaded another DEMO.

The problem seems to happen when the bigger content extends off the bottom of your window. It can actually happen on the same button. So find the button where the big content just extends off the bottom of the viewport, then click it multiple times. The big content will display fine but the small content will jump out of position.

The problem also happens across buttons as I mentioned before. So click a button where the big content extends off the bottom. Then click a button bellow and the small content will be mis-positioned.

Thanks for looking into this. Maybe this can be fixed by putting an extra layout() or resize() call somewhere? I'm just not sure where the right place is...

[Arlo White]

The title of this ticket should probably be changed now that I understand it better, but I can't change it. Can you?

Something like

Shared TooltipDialog? loading different size remote content positions smaller content wrong

Kind of a mouthful though...

[bill]

Ah I see, thanks for the minimal testcase. I was able to reproduce the problem in 1.4. It works in 1.5 though.

[Arlo White]

I still see this problem in my application when using Dojo 1.5.0. However, I confirmed that my minimal demo doesn't exhibit the issue with Dojo 1.5.0.

I will try to create a new demo that exhibits the bug with Dojo 1.5.0 in the next week.

In the meantime, my solution for the app is to manually call refresh on the TooltipDialog? and then call openDropDown after refresh completes.

openDropDown:function(){
	this.dropDown.ioArgs.content.sectionId=this.sectionId;
	var def = this.dropDown.refresh();
	var args = arguments;
	def.then( dojo.hitch(this,function(){this.inherited(args);}) );
}

This seems pretty goofy/hackish, and the user doesn't see anything until the remote content gets loaded, but it avoids the layout issue.

[Arlo White]

I'm having difficulty recreating the issue outside my application. The only thing I don't like about my workaround is that no loading message is displayed.

I introduced a delay on the server side so I could see the original loading message behavior.

With my original code, I noticed that the very first tooltip has no loading message. Successive tooltips show a loading message, but it is positioned based on the old tooltip size instead of the resized size of the loading message.

I'm not sure how to easily create this delay in the demo code to demonstrate this.

It seems like dijit.popup is positioning the tooltip based on the old size, then the ContentPane? code gets invoked, which replaces the content with the loading message, resizing the content smaller, resulting in the loading message being out of position. Then when the content loads, the tooltip changes size but the popup isn't repositioned.

It seems like 1.5.0 fixed a certain case that the demo I attached exhibits, but there's other layout issues with TooltipDialogs?.

Should I create a new bug for the missing loading message issue? "First load of TooltipDialog? attached to DropDownButton? doesn't show loading message" and if refreshOnLoad==true "Reloads of TooltipDialog? content show loading message out of position"

But since this is all related maybe it should all be part of this issue?

[Arlo White]

After trying to force loading messages I'm starting to debate the value...

Since the loading message is a different size, it can result in the loading message being displayed below the DropDownButton? and then on content load, the popup will move above because it's too big.

At faster speeds this would just look like a flicker below your button and then above.

In general I think loading messages should only be displayed if the request takes longer than a certain short amount of time. But this is a whole other subject...

Also, maybe show the loading indicator on the DropDownButton? instead of in the popup, which may end up jumping around.

I feel like this discussion belongs somewhere else, but I'm not sure where.

[bill]

Feel free to have the discussion on dojo-contributors. I'm going to close this until you have a self contained test case, but even then maybe you should open a separate ticket as the original problem reported, or at least the original test case, is fixed.