After weeks of hard analysing issues we end up in a dead end. On the Mac SUalive Free version roughly works but as soon as we switch to another tab (e.g. layers) Javascript stops at the first window.location instruction. No error, no message and we can click any other tab with the same result. Javascript stops at window.location. Ruby add_action_callback() never reached. Of course no issue on Windows where code works perfectly. I join a picture to make this a bit clearer if so.
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.
One that should be high on your list is that javascript on Safari is asynchronous. That is, when it does a skp: window.location call it does not stop and wait for SketchUp’s Ruby callback to return, it continues immediately to the next javascript statement. It can run ahead and actually “swallow” subsequent events. ThomThom discusses this in his Lost Manual.
Are you aware of the WebKitInspector? It is built into the library used by SketchUp but must be enabled by a defaults setting before it is available. It includes a javascript debugger.
First my above description is not right. Javascript doesn’t stop but ignores window:location skp: then goes on next instruction. Here the following instruction is merely an alert(‘I am after w:l’). Of course I am aware of safari asynchronous javascript and also know about ThomThom lostManual.
But I know nothing about WebKitInspector which is Mac dedicated. I have just read your topic webdlg debugging on Mac using WebKit inspector • sketchUcation • 1 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
Unless you have tried it, I don’t know what to respond. It will flag javascript errors that can otherwise be silently swallowed. It allows breakpoints, single-stepping, etc. But it is definitely a developer’s tool that requires understanding of both javascript and debugging in general.
I have offered before, and asked if you will supply a working animation example…
I don’t have time to learn your plugin, make an animation and test the GUI, but will test with a ‘known to work’ example and simple instructions of how to run that on my machine…
for your mac testers, setting a global default in Terminal.app is the easiest way to ‘enable’ WebInspector…
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!
by default all new WebDialogs can be accessed using a right click…
I don’t know how you have managed to block ‘right clicks’ and I obviously can’t read your code to check, so you will need to do a search in your html, js and css code…
the ‘blocking’ is on both the license and main dialogs…
and I did test your latest and it stops after the js Alert without doing the Puts
According to references, contextmenu is a global attribute that can be put onto any html element. It specifies the id of a menu element that has type=“context”. The onclick event of that menu element can specify javascript to execute. So far as I could determine, although these attributes are new in HTML5, there is no global setting to disable the contextmenu attribute per-se. But one could defeat them by putting in contextmenu attributes that specify menus with no content.
It seems to me possible that your developers deliberately put in such “dead” context menus after realizing that if a user can invoke a debugger they can inspect your html and javascript despite your encrypting the extension files, thereby exposing intellectual property. If that’s what’s going on, unless you provide an unencrypted version to beta testers, only the developers can debug to investigate what is causing the issues on Mac.
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.
Hello slbaumgartner
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.
the beauty of ruby and javascript is it’s readability…
even with WebKitInspector, your js is not ‘human’ readable, but I’ll give you some observations of where I think your code goes wrong…
in the Quick Start video you show ‘collapse arrows’ as the last item on the top menu…
I guessing this was document.getElementById("qbqpd") that’s now throwing the error because it was left in the JS code…
I’m assuming that to replace this ‘collapse’ functionality the onClick behaviour on ‘Layers’ or any others is now switched using conditionals…
it is very convoluted to read but I’m guessing this is where your loosing the ‘write back’ from ruby…
without ‘human’ readable code I can’t investigate any further than simple observation…
Going forward, I think your efforts to encourage a SU v17 version would be easier to achieve, and should gain wider company support as it will be needed for the PC version when SU drops IE support…
The Chrome based browser SU now uses is also WebKit based and HtmlDialogs make cross platform support much easier [that’s why they’ve been added]…
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.
The longer I go on the more aware of OSX asynchronous Javascript means. Have a look to code raising the on load error.
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?
