md-tooltip positioning problem with md-panel change

[fsmeier]

Actual Behavior:

• What is the issue? * The second time the tooltip appears it is not positioned correct when $compileProvider.debugInfoEnabled(false)
• What is the expected behavior? tooltip should stay on top

CodePen (or steps to reproduce the issue): *

• CodePen Demo which shows your issue: http://codepen.io/anon/pen/mWQJve?editors=1111
• Details: when $compileProvider.debugInfoEnabled(false) it does fail; with $compileProvider.debugInfoEnabled(true) it works as expected

AngularJS Versions: *

• AngularJS Version: 1.5.5
• AngularJS Material Version: 1.1.3

Additional Information:

• Browser Type: * Chrome + Firefox
• Browser Version: * Version 56.0.2924.76 & 52.0.1 (64-bit)
• OS: * kubuntu
• Stack Traces:

i was searching for hours. The new "small" version update changed a lot of basic things. i rly was suprised. when md-tooltip switched to use md-panel it stoped working correctly. I found out that it has sth to do with debugInfoEnabled(false). But why should this affect the tooltip/panel ?

is there any hotfix or workaround for it? just simply enabling debugInfo is not a solution.

---

Shortcut to create a new CodePen Demo.
Note: * indicates required information. Without this information, your issue may be auto-closed.

Do not modify the titles or questions. Simply add your responses to the ends of the questions.
Add more lines if needed.

Best,
Florian

[tyrdavis]

Thank you for the info about debugInfoEnabled(false)! I had been seeing this issue on my app but couldn't figure out how to replicate it to post a bug ticket.

[fsmeier]

maybe @bradrich has an idea?

[bradrich]

@IMM0rtalis I am not actively helping with this project at the current moment, but I can ping someone that is: @crisbeto and @EladBezalel

[tipodisimmia]

+1

[fsmeier]

@EladBezalel whenever you need help or testing on this -> i am available!

[geertjansen]

+1

[fsmeier]

@ThomasBurleson Do you know what is the status of this project? How can I help? At least bugfixing... New small versions should just fix bugs and not make new changes with new bugs :/ Atm it seems that nobody have the time to maintain this project anymore. :( Maybe it is time to stop all features and rly just do bugfixes and "finish" this version.

[nurishi]

I'm also the one suffering from this issue since 1.1.2 and had to decide to stay on 1.1.1 for my project.
I also spent quite a lot of time to create a small sample to reproduce it but had no luck.
Great to see the findings by @IMM0rtalis and wishing this issue to be solved.

[EladBezalel]

@IMM0rtalis sorry for late response, if you can fix it and file a pr that would be good!

[fsmeier]

@EladBezalel I can't because i don't know where to start. That's my problem. Otherwise I would have created a PR already :( Maybe you have ideas where the problem could be or where I should look?

[EladBezalel]

Well that's some dark magic over there!

I assume you do want to do it on your own therefor i'm guiding you what i'd do -
I would've start with going into the open tooltip method and inspect the panel positions with and without the $compileProvider.debugInfoEnabled(true) and work my way through where it gets the position from and start to figure what's wrong,

I'll let you play with it, ping me here or send me an email at any time - worst case i'd find sometime and we will solve it together!

Thanks again

Love your attitude

[oliversalzburg]

So far, I can tell that panelWidth will be 0 the second time around, when the result is a misaligned tooltip: https://github.com/angular/material/blob/master/src/components/panel/panel.js#L3102

Which I find pretty weird, because when I inspect the panel, it seems to be 90px wide:

[oliversalzburg]

My guess is that the injection of the Angular debugging information will delay DOM operations just long enough for the width lookup to succeed and return the correct width.

When debug info is disabled, the process is too fast and will fail.

This can be "fixed" by introducing an artificial delay. I wrapped these lines into a setTimeout and that resolved the issue.

Maybe someone can translate that information into a proper fix?