New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

loop initialization with new version of uploadcare 2.5.x #281

Closed
sinsunsan opened this Issue Oct 28, 2015 · 13 comments

Comments

Projects
None yet
8 participants
@sinsunsan

sinsunsan commented Oct 28, 2015

After having upatated to latest version of uploadcare in my installation, 2.5X with jquery 2.1, I had a flickering effect. After investigating it I notice html element was like disapearing and reapearing.
I put a watch on it and figure out
that
this function was being called repeteadly

uploadcare.namespace('', function(ns) {
    var cleanup, dataAttr, initialize, initializeWidget, selector;
    dataAttr = 'uploadcareWidget';
    selector = '[role~="uploadcare-uploader"]';
    ns.initialize = function(container) {
      if (container == null) {
        container = ':root';
      }
      return initialize($(container).find(selector));
    };

and called that function from jquery.sizzle

if ( newSelector ) {
    try {
      push.apply( results,
        newContext.querySelectorAll( newSelector )
      );
      return results;
    } catch(qsaError) {
    } finally {
      if ( !old ) {
        context.removeAttribute("id");
      }
    }

Uploadcare is not compatible with jquery 2.x branches ?

@dmitry-mukhin

This comment has been minimized.

Member

dmitry-mukhin commented Oct 28, 2015

The Uploadcare plugin searches for new widgets on the page every 100ms. This is called live initialization. Internally the plugin uses jQuery (which uses Sizzle selector engine) and this is how Sizzle actually works: it adds id elements to the root element of the search scope before the querying and remove it after. You can verify this with a simple example:

<script src="https://code.jquery.com/jquery-2.1.4.js"></script>
<script>
  setInterval(function() {
    $.find('[attr]', document.documentElement);
  }, 200);
</script>

If you want to avoid flicking, you have two options. You can disable live initialization at all by adding UPLOADCARE_LIVE = false; to js code. Or you can add any custom id attribute to the html tag. Sizzle will not change it.

In the future, we are planning to use MutationObserver to watch for the new widgets on the page.

Sorry for the copypasta.

@sinsunsan

This comment has been minimized.

sinsunsan commented Oct 28, 2015

@homm

This comment has been minimized.

Contributor

homm commented Oct 28, 2015

Sébastien, that effects all from the Elements tab repainting in Chrome Dev Tools for sure.

You have two options to fix it. You can disable live initialization at all by adding UPLOADCARE_LIVE = false; to js code. Or you can add any custom id attribute to the html tag. Sizzle will not change it every 100ms.

@markbao

This comment has been minimized.

markbao commented Jul 16, 2016

Thank you - I was wondering why Chrome DevTools' elements pane just wasn't working.

@sinsunsan

This comment has been minimized.

sinsunsan commented Feb 1, 2017

It is 1 year and more that I posted this issue.
On another project, I used latest version of uploadcare widget. Forget about that issue, and have little css debuging to do. So it does not disturbed me so much.
But I noticed that I was unable to edit the css directly in chrome debug dev because of this annoying effect that refresh everything...

But I forget a bit about this issue, and thought it was another problem.

But in fact it was this very issue and it is 1 months ++ I am working with this annoying default because of uploadcare.

I suggest that you set UPLOADCARE_LIVE = false; by default, because many people probably are loosing time like me.

And it is a problem that is difficult to put a name on to search in google. Like a clear debug error message.

I do not know why it is not fixed in a more stable way now. @dmitry-mukhin

@dmitry-mukhin

This comment has been minimized.

Member

dmitry-mukhin commented Feb 1, 2017

Lucas,

while we still haven't implemented MutationObserver (we're working on widget 3 at the moment), the problem affect far less users compared to changing default to disable live init.

Do you think that adding a message to JS console (e.g. how Facebook does this) will make you happy?

@Zmoki @homm please pitch in on this.

@sinsunsan

This comment has been minimized.

sinsunsan commented Feb 1, 2017

If you are able to detect who have this problem yes a console log would be a way to at least guide them to the solution.

The fact that a library is able to make chrome debugger unusable at least regarding its live css editor (right panel in the element tab) seem to me strange anyway.

@dmitry-mukhin

This comment has been minimized.

Member

dmitry-mukhin commented Feb 1, 2017

In any case changing this default breaks compatibility, so I'd rather press for implementing MutationObserver workflow.

@maxfi

This comment has been minimized.

maxfi commented Apr 26, 2017

If you are able to detect who have this problem yes a console log would be a way to at least guide them to the solution.

I agree with @sinsunsan. This issue made my dev tools almost unusable and pegged my CPU. It's also hard to track down and troubleshoot. Although it is mentioned in the docs a console.log referencing the docs would definitely be a good idea!

@williamli

This comment has been minimized.

williamli commented Sep 29, 2017

I too wasted a few hours on this (and it slowed down my dev time for about a day till I notice the flickering)

@williamli

This comment has been minimized.

williamli commented Oct 1, 2017

Regardless of what UPLOADCARE_LIVE 's default settings should be, this "feature" should be listed as part of the documentation instead of hidden as a GitHub issue. This would have saved a lot of our time if this is documented in the public doc.

@kyle-ssg

This comment has been minimized.

kyle-ssg commented Oct 9, 2017

This needs to be added to the docs!

@Zmoki

This comment has been minimized.

Member

Zmoki commented Oct 10, 2017

Ok, thank you! We'll update our docs soon. And with next major version of the widget we'll change this behavior of the widget.

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