How exactly would this work? If it would be the block that @alexphan had in the previous page, then when the user was directed to another page in the same tab, then when they came back to the project, they would never be able to finish it. The project would start over again, and the user would be directed to the same page again… you get the idea. If users who didn't understand this concept used it and put more scripts after it, then their script behind it wouldn't work at all. Instead, I support this:

open [scratch v].mit.edu/[projects v]/[numbers] in [new page v]:: sensing cap // you can choose if you want it in a new tab or page ONLY
//notice how it's a cap block, so there won't be anymore scripts after it, and how it's in a new tab/page, not the same

Support for a block that looks somewhat like this:

open link [https://scratch.mit.edu/discuss/topic/29084/ v] in a new tab and stop project::sensing cap
// https://scratch.mit.edu/, links used in project, new lin

where in the dropdown where you click “new link,” a dialogue appears where you can enter a link to part of Scratch or a subdomain of Scratch. If the link is not part of Scratch/not a link, it will notify the user. When a valid link has been entered, the link is available in the dropdown until it is not used (like broadcasts). (except for https://scratch.mit.edu/, which acts like “message1” and can't be deleted no matter what) Upon running the script, the project is stopped and a new tab with the specified link is opened..

theonlygusti wrote:

I won't support this, but I have my own ideas for it anyway:

send user to http://[scratch v].mit.edu/[]/ :: control

The first drop down has two options:

1. scratch
   
2. wiki.scratch
   

And when the block is called it should pop-up an alert saying:

"(name of project)" would like you to visit link to page.
No Thanks. Go to web page.

And if you do open up the page, it opens in a new tab.

I support this.

This is what it should look like

go to [scratch.mit.edu v]/[projects v]/[] :: sensing

The first dropdown will include the scratch website and the wiki, and the second will include discuss, discuss/topic, discuss/topic/?page, project, studios, etc.

Invisible_Factory wrote:

This is what it should look like

go to [scratch.mit.edu v]/[projects v]/[] :: sensing

The first dropdown will include the scratch website and the wiki, and the second will include discuss, discuss/topic, discuss/topic/?page, project, studios, etc.

I support this design for the block and the suggestion for a confirmation popup box.

Invisible_Factory wrote:

This is what it should look like

go to [scratch.mit.edu v]/[projects v]/[] :: sensing

I support this, however there is an easy way for people to get around that:

when green flag clicked
go to [scratch.mit.edu v]/[projects v]/[../accounts/logout] :: sensing

It will log yourself out.

Another problem I thought of with this block is that the JSON can be edited and blocks can be put in the drop downs. This means that people could be brought to sites other than Scratch unless the block somehow detects this change.

iamunknown2 wrote:

when green flag clicked
go to [scratch.mit.edu v]/[projects v]/[../accounts/logout] :: sensing

Good catch! ..ing shouldn't work with the block, but how would the ST prevent this? I mean, if it works in URLs, for example scratch.mit.edu/discuss/topic/29084/../../1, then I'm not sure what they can really do. In-block blacklisting of this and other cd-related commands wouldn't work, because you could still hack it into the block input.