Flickering and sizing in UIOptions

Justin Obara obara.justin at gmail.com
Thu Aug 11 14:43:14 UTC 2011


I've been meaning to chat with you about this all week. It's great that you got a head start on it. Seems like we've been playing IM tag for a while. :)

I have some  comments inline below.

Thanks
Justin

On 2011-08-11, at 1:26 AM, Antranig Basman wrote:

> I have been investigating FLUID-4397 to deal with the last of the issues Colin reported during his integration with WordPress over the weekend. My impression is that the issue is not what it seems... for a start, in grilling various community members this evening I haven't found a clear impression of why exactly the panel is made visible on startup and only hidden after the components have fully loaded.
> 
> Some accounts pointed to this code in the UIEnhancer -
> (line 268)
> 
>    fluid.uiEnhancer.textSizer.calcInitSize = function (that) {
>        that.initialSize = fluid.uiEnhancer.getTextSize(that.container);
>    };
> 
> but there doesn't seem a clear reason why this information
> 
>    fluid.uiEnhancer.getTextSize = function (container) {
>        return parseFloat(container.css("font-size"));
>    };
> 
> wouldn't be available as soon as the markup loaded, whether visible or not.
> 
> Indeed, simply adjusting the markup at
> 
> demos/uiOptions/FatPanelUIOptions/html/uiOptions.html   line 52
> 
> to read
> 
>     <div id="myUIOptions" class="flc-slidingPanel-panel flc-uiOptions-iframe" style="display:none"></div>
> 
> appears to resolve the headline JIRA in that the jumping no longer occurs. The component appears to work perfectly well with this change, but perhaps someone more familiar with the expected oddities could try this out and point to something I have missed.

So this issue materialized as a fix to the issue where the text size and line spacing wasn't being calculated properly on instantiation. (note that this was only an issue in Firefox). We had discussed this problem at one of the dev meetings and the suggestion was to initialize the iframe and uio first, offscreen. After that had been completed, we would init the sliding panel and  put the iframe back on the screen. 

Cindy has since removed the code that did the initialization  offscreen, so things may some how have corrected themselves. So I think the first thing we should try is to initialize the sliding panel first. I believe that it only flickers because it has to wait for all the other parts to init before it starts.  (note that on initialization, the sliding panel will close itself by default. ). 

> 
> 
> A more serious issue found in looking at this, though, is the issue of the sizing of the panel in the first place. In order to get this variably sized iframe dialog to appear without scrollbars or clipping would require dedicated code, basically executing on every significant DOM manipulation within the dialog, to make sure it was sized correctly. I don't see any evidence of such code lying around... in talking to Michelle this evening it seems that it might either be lying around in a branch someone, or else in someone's head. She thought perhaps Justin_o might be the clearest memory of what the status of this impl is.
> 
> I find a JIRA for this reported by Heidi at http://issues.fluidproject.org/browse/FLUID-4342 - this issue should IMO be a release blocker since the component is in many cases unusable without it. I have raised it and added it to Bug Parade (Peace Be Upon The King)

This one was already on bug parade as FLUID-4371. I had forgotten that Heidi had already filed it. I've now closed FLUID-4371 as a duplicate. That being said, I think  this one will be related to the previous issue in the sense that it will have to calculate sizes when the content is hidden.

> 
> Antranig
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work



More information about the fluid-work mailing list