-
Notifications
You must be signed in to change notification settings - Fork 6.7k
Conversation
Nice work Gino. How was $transition? ... sent from my tablet
|
Worked like a charm! :-) |
You shouldn't need |
Exactly, forgot all about that one. |
@typesafe Sorry for the delay but finally I had some time to have a closer look into your PR (which I want to merge ASAP as it contains great stuff!!!). So, pre-merged this PR into a separate branch (pr36) and there are things that need more love:
Once again, thnx for all the hard work, this is great stuff, we are close to landing it. |
@pkozlowski-opensource, I'll look into this as soon as I find some time in the coming days! |
@typesafe cool, don't stress! We are working toward the very first release and I would love to land your PR but once again, it is better to wait few more days and not to rush things! |
@pkozlowski-opensource, I just ran all tests on Safari (version 6.0, on my MBP) and they all passed...
I ran them from both my local repo, as well as from a downloaded copy of the pr36 branch. Are you aware of any particularities with the Jenkins CI build? |
@typesafe bah, don't know what is going on with those Safari tests (although I saw some strange things going on already). Could you do other changes (remove the |
@typesafe just run the tests on my local machine and things are OK (Windows, Safari 5.1). Really not sure what is going on here... Could you do other changes so we can have a look at what is going on? |
removed docco /docs files and /src/bootstrap.js and added /src/dialog/docs files for the demo page.
@pkozlowski-opensource, here it is. Feel free to edit the demo page. Let's hope Safari behaves better this time... |
@typesafe Gino, grr, seems like there are still problems with the CI build for Safari: I'm not sure what is going on as those tests pass on my side :-( I will try to look into this later today / contact guys at Google but if you've got any ideas feel free to submit patches to the PR. |
BTW: tested demo locally and it is simply AWESOME!!!! |
@typesafe I think I know what is going on, it must be linked to some clean-up not happening to which Safari is vulnerable. I've managed to reproduce it locally by capturing multiple browsers (in other words, this test starts to fail as soon as you capture multiple browsers). You can see this by doing:
So, at the end of the day there is a real issue here, CI server is working just fine. |
@pkozlowski-opensource, I used pretty much every browser I could find on my local network and combined it in several ways... Here's a sample of the (inconsistent) results while (somewhat) simulating the CI env (run testacular, run tests once, then stop the whole thing):
...
...
...
...
...
On some runs, Chrome took a LONG time to complete the tests, but they were successful nonetheless... Note that it is only Safari 6 that fails the tests (and not only as last one in the queue). Then I started leaving testacular alone (run Save dialog.js (we were lucky :-)):
Save file again (not so lucky, however - no changes):
Save file again:
And again... (WTF?!)
I'm starting to think this is a testacular issue... but then again, why is it mostly Safari and sometimes another webkit browser? Weird... Then I altered the grunt file to use testacular's
However, ALL subsequent runs (invoked by saving an unchanged files) were successful (no matter what browser combo, this is just a sample):
I'll try to get to the bottom of this. But any help is much appreciated! ;-) |
2 quick remarks:
I will try to look at this during the weekend. I'm still suspecting some cleanup issue. |
@typesafe just one thought - didn't try this - but maybe it is backdrop that stays attached to the body and not removed? |
It is indeed the backgrop that remains attached to the DOM... with On the bright side, it is easily and consistently reproducible with the exception of mostly it's Safari sometimes it's Chrome and very rarely it's FF. One way to avoid the issue, would be to only create the backdrop element when it's needed. That would require a bit of 'bookkeeping code', but that's it. I'll try to get to the bottom of this later today (if I can free the time), but I'm afraid it'll remain a mystery :-(. Anyway, there's a solution in the make! |
@typesafe ok, good that we know what is going on. I was also thinking that it might be other modal directive interfering here. I think that adding and removing the backdrop element as needed is acceptable. Alternatively we could remove this element after each test (afterEach), no? Didn't try this, just a thought... |
@pkozlowski-opensource, there already is proper clean-up in the dialog tests:
But you were right on the modal directive interfering! For some reason at first run testacular does not clean-up the context iframe properly (something to look at I guess) and the backdrops introduced by the modal directive tests remained present in the DOM! Adding this to the modal directive tests seems to resolve the issue:
That was a nasty one! I'll try to push an update today... |
@typesafe glad that you've managed to pin-point it! It was a tough one, I must admit! But at least now you know everything about Jasmine tests and testacular :-) |
Added an afterEach to the modal directive tests that removes all modal-backdrop divs from the DOM. They sometimes interfere with the dialog tests (making 13 of them fail), probably due to a testacular glitch.
Tried putting the demo up on JSFiddle but it's not working for me on Chrome. http://jsfiddle.net/9gYGf/ |
@alexhanh Thnx for looking into this one but the issue was thet your jsFiddle wasn't well configured, there were multiple problems really, but the most important ones were:
Here is a fixed jsFiddle: http://jsfiddle.net/9gYGf/2/ Hopefully I will have some time to merge this PR later today so we will have a demo, docs etc. |
Thanks @pkozlowski-opensource. Time to update my apps :-). |
I thought, reading docs and examples, that messageBox didn't need a template, Infact you don't see any template mentioned for it in https://github.com/angular-ui/bootstrap/blob/master/src/dialog/README.md or in http://angular-ui.github.com/bootstrap/#/dialog. But then, if I don't define any template, the default one is not picked up and I see a 404 error as browser tries to load template/dialog/message.html from localhost. In order to solve that, I manually copied in my HTML page the template taken from the source code:
Maybe in next versions you want to make that more clear. Thanks for all this great job you're doing! |
This PR replaces the previous one I closed.
I moved all dialog work to a feature branch, and then rebased and squashed it all into a single commit on master.
I also updated the code to use the new
$transition
service.