I saw two bug reports just come through for locale language and the composer scene transition gradient.
Rob
Yeah, they are those.
Marco
Hello there,
me also I reported a bug recently (two weeks ago?) about the “userinput” event (for native textFields) not working correctly in the most recent daily builds, and didn’t get a notification.
Could you please confirm reception?
We have the bug report in the QA queue to investigate.
Rob
Thanks Rob - you have to fix the automated responses to save time! :blink:
I searched our support portal and the only communications I see with your email address is with me about a year ago. About a year ago, we changed our support portal, but bugs should have been transferred to our internal bug tracker.
As for GitHub, I know we recently processed a pull request for the timer library, but I don’t remember seeing any get processed for widgets. The problem is GitHub holds a copy of our libraries, not the core source. That’s maintained in a separate source control system. We kind of have to hand process all pull requests. We have traditionally made the source available for you to change for your projects, not provide a path for you to contribute updates back into our core.
If you can provide me a list of the things you reported I might have a better way to look them up and get a status on them. As far as I know our “Report a bug” link is working correctly. But I’ll give that a test too.
Rob
Thanks for the reply, Rob.
If you don’t see my bug reports, I can try to report them again so you can check if they are actually arriving at you, if you want.
Anyway I am sure that at least 2 weeks ago I have reported 2 bugs though the “Report a bug” form found here.
Also, if I make a list of the bugs that I am occurring, I have to post it here or via email?
Marco
Oh, I was also forgetting to tell you that I have also reported an issue to a page of Corona Doc, but again I haven’t received a response and now the page still contains the error that I reported. I’ll include it to the list.
The documentation issue must have been a temporary glitch. Can you try that again?
You can just post your issues here and I can see if I can find them.
Rob
- “WARNING: line.width is deprecated. Use line.strokeWidth” on log when adding a line to a scrollView (reported on corona-widget github repository and through the Corona site).
- “system.getPreference(“locale”, “language”)” returning “en” even if the language on the device is set to a different language from english (tested with italian language, the bug occurs only on macOS 10.14 and iOS 12, reported through the Corona site).
- On this page of Corona Doc it says that the syntax “math.inf” will produce an infinite value. But in the reality math.inf is nil. Instead, on the examples, it’s used “math.huge” and in fact that works. It’s confusing (also note that the page itself it’s called “math.inf”). There is also a “math.huge” site that it’s correct, but it’s not listed on “math.*” index page (reported through the form on the bottom of the doc page).
- On this page of Corona Doc it says that you can use both left/right or x/y to position the tabBar. But in the reality the x/y values are totally ignored, they work only if you set them later (reported through the Corona site).
- Sometimes the progressView it’s not correct. I noticed that at some particular width (usually < 100), setting the progress at < 0.5 it doesn’t show the correct percentage (reported through the Corona site).
- When using the scrollView horizontally, while scrolling to the edge of the scroll view doing the bounce effect, pressing on the scrollView before the animation ends, the scroll it stops in there even if it’s out of its limit, interrupting the animation completely (reported through the Corona site).
Here’s what I can tell you.
-
Yes, it’s on the GitHub repository. Is this causing you issues? It seems like a harmless warning. When we open sourced the various libraries, the intent was you could take the code and modify it for your use I’m not sure we really planned on having people contribute back to it. The GitHub repo is generally a copy of the last public build and isn’t updated with daily build changes. Its even in a physically different repo than we use to build Corona so any pull requests have to be manually copied back. This would have been better as a bug report, but honestly, it’s going to be a low priority fix unless it’s breaking something.
-
system.getPreference(): This bug is not in our system. We have identified a problem with the bug submission form and some attached .zip files being flagged as dangerous. Our team is working to solve this issue. In the meantime, you can resubmit, perhaps just attaching the main.lua file. This is not our preference, we would really like a complete project, but in this case, just a main.lua will do.
-
We have discussed this on a different thread and email chain. There is no math.inf in Lua. math.huge returns “inf” which is a value in Lua. I don’t know why our how Google indexed the math.inf page. I’ll try to figure out why math.huge isn’t in our math.* index page.
-
tabBar not respecting .x and .y in the creator. This bug is in our main repositories issue tracker, where bugs go to get fixed. This is grouped with two other tabBar positioning related bugs and the group is marked as a high priority, however, this particular issue has a good workaround.
-
progressView: I don’t see your submission. I’m checking with the QA team to see if they have seen it. There is a similar bug already in our main issue tracker, so it may not have been added since it’s a duplicate. No ETR on the bug that’s already there.
-
scrollView: same as progressView, except I don’t see a duplicate in the main issue tracker.
Which of these are preventing you from releasing your app?
Rob
Really thanks for the effort.
The main thing that is preventing me to release my app is ofc the 2nd point because I have a translation system, so if the language cannot be taken correctly it’s a big problem.
Also the 6th it’s pretty important to me because I use horizontal scrolling on my app.
I’ll resubmit the report for both.
The 1st point is also pretty annoying in my case, because I use lots of lines in a scrollView, so having lots of this warnings on the console while debugging it’s not helpful. But ofc, as you said, this isn’t breaking anything so I think that it’s ok the low priority.
The others are more marginal (also because I used workarounds/made my version).
Marco
I’ve confirmed with QA that we have not received either #5 and #6. The problem with the submission forms is a change in an upstream provider is treating some compressed files as unsafe and filtering the messages before they get to us.
If you can resubmit them, attaching just the necessary Lua file files, we can get them into our system.
Rob
I reported again the #2, #5, #6 and even a new bug that I just found (for me the issues that bother me the most are #2, #6 and this new one that I have reported).
Marco
Did you attach zip files to the submissions? I don’t see them.
We updated the forum to ask you for a URL to where your .zip file can be found rather than trying to include a .zip file in the actual submission
Rob
I just put a shared folder link with Mega thought it was the better solution since you said that some zip files are causing problems with you 
If now a zip file is required I’ll do that again hoping that it gets accepted.
Marco
Let me re-phrase that. I don’t see your submissions in the system. It’s almost like you attached .zip files and they got blocked. We have redone the form to ask for a URL to a .zip file you host on Google Drive, DropBox or some other place to upload files to so the emails the for generates doesn’t get blocked.
I didn’t know if you resubmitted before we made the change.
Rob
I have used the new form, but instead of an url to a zip folder, I have put an url to a shared folder (using Mega). Maybe it hasn’t worked because of that?
Marco
Any update on this?
I haven’t seen any new reports from you since this thread started. I’ve asked the QA team if they have seen them since they get assigned to them.
Rob