Please tell me all what you know about window.location issues on Mac. I suspect underlying problems when the first tab is shown - at run time - but really no longer know where to start. The more I know before diving into debug the best chance to achieve.
Feel free asking any details and thanks in advance for your help.
But I know nothing about WebKitInspector which is Mac dedicated. I have just read your topic http://sketchucation.com/forums/viewtopic.php?f=180&t=49169 but our beta-testers are not developers and I’m afraid they do not know more than I do. On the other hand I doubt they would like - provided they have abilities - spending time debugging (I asked them but they have no time). Do I miss anything about WebKitInspector?
Unless I find anyone with abilities and time, I’m at standstill
The easy way to check is to right-click in the WebDialog. If you get a popup menu, you are allowing context menus. With WebKitDeveloperExtras active, the menu will include an “Inspect Element” item that opens the WebKitInspector.
Very sorry John! I misunderstood your offer and I really thank you.
Don’t worry. I will never ask you for animation making or globally test the user interface. I’m not that kind of guy making the others at work then go to have good time. We always follow the same process.
Testers install SUalive.rbz I provide a link for.
I send an e-mail precisely describing some actions to perform involving window screen copy and/or Ruby console content copy. No more than that.
All questions are closed-ended ones and clearly noted - 1, - 2, - 3. Rarely more than four or five questions you only reply Yes or No.
So tests take only some minutes, no more.
If it’s good for you send me your e-mail address. Please feel free to not agree. I am fully aware of how annoying can be such process.
In return I will be pleased to offer you (or anyone instead) SUalive Full version.
I am happy to test the GUI extensively to help this work on a mac, but to do so I want a working file-set that I can point your extension at click run…
once I know what that does I can systematically try different settings and confirm if they work or not…
if I can access WebInspector I can inform you if the JS side is working…
you already sent me SUalive and SUaliveOSX rbz links and I have run both in v16 and v17, without a complete working animation…
if you have a newer version, Message me the link, like the last time…
You offer SUalive more than we expect. So your way is good for me!
Current SUaliveOSX rbz is up to date and I’m going to message you a link to cubePrj.zip you just have to unzip any folder your choice then load from SUalive. I will let you know any time I update the extension.
In order to you not spending to much time you may reproduce the bug following this:
After Cube project loaded and from The ‘Project’ tab which should look like the picture
Click ‘Layer’ tab. You get a message “WinLoc Frist Call” meaning you are right before windows:location skp: After you click OK Ruby console shows a message - puts “something” - you will never see.
‘Layer’ tab should look like that which demonstrates ruby code never reached
‘Layer’ tab on Windows here
I look forward WebKitInspector is going to yield and your take too!
Yes John. Unfortunately Ruby method never reached! So the tricky bug comes before. But Where?
As I know nothing about WebKitInspector I suspected code to allow specific context menu.
I’ve just updated SUalive rbz you can download then now access context menu.
Developers did! but what matters the most is knowing where is that bug. I assume they have enough abilities to jump over! in my humble opinion only developers having written the bugged sequence can provide a consistent solution. At least it’s what I am after.
I’m not sure what you want from us here. Perhaps it isn’t clear to you that the problem lies in your extension code, not in sketchup. It is your developers who have obfuscated the code, and we are therefore unable to tell you where or what is the source of the problem.
I just would have liked SUalive at work on Mac OSX! I said for long SUalive was Windows designed and we all have only strong Ms background and know nothing about OSX. So the project is not for us but so that thanking Mac users to help me so much in the past. I wrote more than once “Mac users helped us so kindly but we have made so few for you” and I keep thinking this is the truth. Note I’m alone to think this way and I’m alone in charge of developing Mac OSX version most of all from my spare time.
Vincent - screen shots come from him, few others beta-testers and now John seem thinking it is worth. This makes me stronger, more active and motivated but the fact we never aimed Mac OSX raises now some hard issues. I am merely making my best to achieve this part of SUalive project and once more not allowed from my work time.
I would have liked to send you a full readable version but unfortunately this is not only up to me. I promise you to make my best so that persuading my peers on the next meeting but they are strict on the matter. Today no HRO has gone out!
I didn’t know SU is going to drop IE support and Chrome based browser replace. That’s probably why we needed to adjust webDialog size from SU17 - SUalive Free is currently under review. This would explain why it should be disabled on Mac. webDialog are too large related to content as you may have noticed. I would have liked to learn more about but have no time yet.
I like your way of analysing which is so near our code works but ‘collapse’ functionality was disabled on your current version. Your observation gives me some direction.
line 102 is meant to fill the empty div DivToFill then go on 103 to check MacOSX. If so adjust font size at 202 - error raised here - which means DivToFill is still empty.
I fixed the issue adjusting font size before calling fillDiv() but why such weird behaviour on Safari making developer life harder? I must say I have difficulty understanding the underlying logic but it should work. Small ambition fulfilled!
You should no longer get the error on load.
I guess you mean inject window.location from an input-box and after having seen “WinLoc First call” message. Running that you get the same output than windows yields in the same order but no change on ‘Layer’ tab. Inspector tell us no more. Please tell me if I’m wrong.
So could be easier to add error code and see what happens. According to what I read code following window.location leads to troubles. I inserted another window.location skp:collapse before the existing one earlier in the same function.
Here is the how to. From ‘Project’ tab click ‘Project’ tab to collapse the window then click ‘Layer’ tab. What I get on windows can be seen in the following picture. You may need to save the gif picture on you hard drive to see animation.
What do you get and inspector?