Finding lots of issues with 3.2.1


#21

Next time it happens, check that selecting another item none text related will allow freehand.

I think the text editing session may still be active on a recently selected text object. Selecting another image etc will rule that out.


#22

OK I’ll try later, but frankly that’s the least of my problems. Blocs has become unusable today.


#23

I have ran into the same problem. :frowning:


#24

@JayWalker, thank you, I’ll try that!


#25

Ah man that sucks to hear.

:pensive:

Buts let’s see if we can find the cause and prevent this in future. What have you been working with mainly today (that caused the most problems)?

• Editing Classes
• Editing text
• Working with Assets
• Other

I’ll have build 1 of 3.2.2 out on Monday so not long to wait for any potential fixes or improvements :+1:


#26

It was fine in the morning, then at a certain point I started seeing regular problems with the freehand margins. I went back to 3.2, which seemed to create a lot more issues that were not present before. It didn’t like going back to 3.2…

Moving back to 3.2.1, the navigation menu is now unworkable and I’ve tried replacing it a dozen times. There are other issues I mentioned like the hero bloc and it’s just really messy. I’ve hit a brick wall with these points and not even tried other things. The site was actually close to completion, but I guess I’ll have to wait for the next beta.


#27

Could you please send me a copy of the file and I’ll inspect to see what is causing all the issues.


#28

I’ve followed this up via email in more detail. Its clear now that you had assigned RTL text direction on the container class. Switching it back to LTR via the class editor is all that is required.


#29

@Norm, what is ‘RTL’ and ‘LTR’? Are you referring to left or right text justification?


#30

No, text direction (google RTL). It’s not the cause of your issues it’s related to the majority of @Flashman’s


#31

(re: unintentional drag and drop behavior)

@Norm, any progress identifying this issue? Any hope of correcting it with 3.2.2? I worked Saturday on a project I’m trying to finish up and had to quit and relaunch Blocs at least 30x that day due to this odd behavior. It’s very frustrating and time-consuming. Please advise, thanks


#32

When you select a text element for editing its value, simply select another element on the page and then the element you wish to assign the margin too and hold shift.

No need to restart Blocs, just select another item then back to the original item.

Hitting escape will cancel edit text more in 3.2.2


#33

I reported this a while back, however the problem remains. It was ticket #1615

If a hero bloc opens on mobile with an animation the text appears normally with a straight fade in, however it remains blank if the direction arrow points up, so that the text arrives from below. To make it appear you have to refresh the page or scroll down at which point it arrives late in a jumpy fashion.


#34

This sounds like drop mode.

If it happens again try hitting escape.


#35

Im not able to replicate that at all. Could it be that you have some kind of window management app running that is effective the windows and how they behave on MacOS?


#36

Hello Norm,

yes, I have Moom from manytricks.com to help me that the windows stay the same size that I adjusted for each software I use. However, Moom does not work in Blocs. Moom works in the left top horizontal traffic light buttons of other windows. In Moom hovering over the green button pops up a window and within I can choose for example the predefined Safari window size. Moom does not interfere in other software I use at all. Only in Blocs the Brics react to the dragging cursor.

Since I wrote this blog entry I tried desperately to create a QuickTime movie about this behaviour for you, but as Murphy law dictates, it did not work to reproduce this error, which anyway comes up sporadically and more often if I work for longer time durations in Blocs.
What I could reproduce is definitely, that if I do it as I described it, the Bric (text or image) underneath the Safari browser react to the dragging cursor movement when resizing the Safari window. The Brics get a kind of frame around wherever I hover over it. Understandable, this must be a normal software behaviour because a user should be able to place a picture into a bric via drag and drop from the finder.
I try for you again to replicate and capture it on QuickTime and publish it here.


#37

Magnet does not work with Blocs either. Very useful using a large monitor. Not sure why it does not work.

Casey


#38

It’s because the main window in Blocs is custom and not a default MacOS window.


#39

Hi Norm,

Regarding my entry in the discussion “Finding lots of issues with 3.2.1” in the forum. I did send my QuickTime video via the bug report, because I could not attach a QuickTime movie here.

I can replicate the behaviour now. I have not tested Blocs 2.2.2 build 2 but in the version before it is still available.
The whole misbehaving happens after I choose to use the Preview in Safari Browser, which then opens onto top of the Blocs app.

I hope it will help you. :slightly_smiling_face:


#40

I’ve tried hitting Escape, Command + Escape, Option + Command + Escape, etc. etc. No keyboard combinations I tried made Blocs exit the drop mode. UPDATE: I noticed today when Blocs entered the drop mode on its own, that hitting ‘Control + D’ caused Blocs to ENTER drop mode (The right panel turned into drop mode view) and hitting ‘Control + D’ again, caused Blocs to EXIT the drop mode. I rarely otherwise push that key combination. I typically ‘drop’ brics by clicking on the brick with the ‘+’ symbol in it. At least for now, I’ve found a way that makes Blocs exit that mode. Would be great if you can find a permanent fix though.