SOLVED - Lightbox Errors confirmed by Corvid, but no fix yet.

I make extensive use of lighboxes, and since the turbo upgrade a few weeks ago, they all fail in various ways.
Since there is radio silence on the forum and the Wix site, I went through the trouble of explaining the problem to “Support” with a lengthy email plus screenshots, and after the meaningless initial auto-response, I got this from them, apparently a human:

Thanks for getting back in touch, we are happy to assist you here!
I will refer this forward to our Advanced Troubleshooting team. They will be able to better follow up on this and further check what could be causing this inconvenience.
We will be getting back to you shortly with further news.
If you have any other questions let us know anytime!

Cool, so I patiently wait for a fix, since debugging and good coding takes time.
A week later, I get this response, apparently another bot message or some intern with an attitude cleaning up stale support tickets (emphasis Wix’s):

Hello, Please kindly be advised, while we support Wix Code features and components here in the Support center, we are unable to provide support for custom coding.

For your needs, we highly recommend using the Wix Corvid Forum, where you will be able to interact with others utilizing Wix Corvid as well as Wix Code experts. Do take the time to search through the Posts on the Wix Code Forum, and do consider posting your request as well. When posting, it is helpful to include what your goals are, the JavaScript code you are working on, and screenshots to visualize the process.     
The forum is reviewed both by Wix staff, and our community. When posting, please make sure to follow the Guidelines for Posting to the Wix Corvid Forum
If you feel you are experiencing a bug in the Wix Corvid API this issue must be reviewed in the forum. 
Have a great day! Chappie, Wix Customer Solutions Expert

Since the old errors continue, and new ones crop up too, and I am instructed to place the “perceived bug in the Wix Corvid API” on this forum, here we go:


All lightboxes worked as advertised in the documentation until about a week ago when this change showed up in the console:

All lightboxes now do the following:
Clicking the CLOSE (close) or the X you get the error “Unhandled promise rejection The object could not be cloned.”
Further, the code in the “.then” does not execute when I get the error message - for example:

Since wix is so slow in loading the lightbox, I change the color of the button or box that was clicked, so the user has confirmation and can now wait for the lightbox to load.

When the lightbox closes, I change the color back to the previous default:

    wixWindow.openLightbox("someLightBox").then(dataObj => {
        $w("#buttonForSomeLightBox").style.backgroundColor = "#FFFFFF";   // default white
   $w("#imgDots").hide("fade");
    });

So the button(s) get colored, but are not reset, due to the “clone” error, for example.

Wix “CLOSE” button or Wix “X” icon cause error:

When I turn OFF the wix button and the “X” icon for closing the lightbox, and use my own button with code, everything is back to normal:
Setting:

Code for my button:

export function buttonClose_click(event) {
 const dataObj = {};
    wixWindow.lightbox.close(dataObj);
}

So, my button works, but clicking anywhere on the page (outside the lightbox) closes the lightbox with the same “clone” error:

Today, I’m also getting a new Wix “API” error.


I like the lightboxes … when they work as advertised (before turbo).
Before I start massive workarounds that produce a vastly inferior UI and user experience, I would like to know if the Wix team is still working on this, or has decided to ignore this.

Corrupt intranet and all that …

… anyone … anyone … Bueller?

Please provide an example of this problem so that the issue can be elevated.

You’ve looked at my site before.
Most of the buttons open lightboxes.
Try any of the buttons, check the messages in the console.
You will always get the “cloned” error, and occasionally the “e.agGridApi” one.

As you’ve correctly observed, lightboxes can be slow to load. I wouldn’t suggest doing this for all of them, but it could help for some. Turn this crappy situation into a chance to speed up your site and improve your UX :slight_smile:

Instead of lightbox, use boxes pinned to screen(you can set to show on all pages if need be) that are hidden or collapsed on load but which you can call with code. Wherever you can, especially for simple messages, try and make the code dynamic so you can cut down on the amount of clutter in the editor and reduce loadtime. i.e. if it’s a simple message and button, change the text or html and link properties of the items.

@skmedia Good advise. I’ve done some rewrites because some code in the lighboxes was failing hard.
Placed it on a regular page - voila, it all works.
I can probably switch half the lightboxes to regular boxes, but I would hate to do all the work, only to have lightboxes go back to normal functioning by the end of the rewrite.

I think it is ridiculous that we have to find work arounds like @David mentioned for basic functions. If Wix can’t make their lightboxes work, then why even have it. But they can’t remove them, because functions like custom login page (like the issue i have been dealing with for 2 weeks where users can’t login correctly because the lightbox won’t close and Wix login fails to resolve the promise) wouldn’t be possible without them unless you go with a custom coded independent solution, but that also causes error with a multitude of apps and other Wix function that are dependant on the Wix CRM and user ID system.

@brainstorrrm It helps the development team when they know exactly what they’re looking for. Please provide a Page and scenario that I can pass on to the development team so that they can handle this issue promptly and efficiently.

Thank you

Hi all,

I have reproduced this and it is indeed a bug. I have notified our developers with a high priority, so hopefully this will be fixed quickly.

As @brainstorrrm noted, the bug occurs if the user closes the lightbox either by clicking on the “Close Lightbox Button” component that is provided by default with all the lightbox templates or by clicking outside the lightbox. Oddly, it does not seem to occur (at least for me) if the user clicks the ‘X’ in the upper-right corner of the lightbox.

The best workaround, as @brainstorrrm noted above: since the bug only occurs when you’re using code to call the lightbox, you can create your own button in the lightbox and add a click handler that closes the lightbox with code:

export function closeLightbox_onClick() {
    wixWindow.lightbox.close();
}

For more information, see Lightbox - Velo API Reference - Wix.com

Make sure you disable or remove the lightbox’s native Close button. Unfortunately, clicking outside the lightbox will still trigger the bug. You might be able to insert code in the calling page that will handle the Promise rejection, and if this error occurs you can proceed with the same logic as though the Promise had resolved normally.

In the meantime, I apologize for the inconvenience and I thank you for your patience.

@chaim-kram
Thanks for the confirmation.
" since the bug only occurs when you’re using code to call the lightbox "
I call all lightboxes with code.
Today, some lightboxes fail to load completely.

Any update?

LMAO - #buttonforsomelightbox #ffffff #imgdots
All a prank?

@brainstorrrm Update: Our little elves are working diligently… The bug fix is in progress. Hopefully I’ll have more news in the near future. Thanks.

Hi @brainstorrrm and others, the bug is fixed! Opening a lightbox with the openLightbox() API now results in a Lightbox that when closed resolves the Promise as expected. Please do let us know if you are still encountering any trouble with this. Thanks for your patience!

Haven’t changed any code yet to verify.
However, a quick check of a current API call to open a lightbox without an “X” or a native close button causes the lightbox to close when you click anywhere outside the lightbox.
Logically, normal behavior should be for the lightbox to only close by clicking the “X” or the CLOSE button, and it should not close by clicking anywhere outside the lightbox (with or without the “X”).

Some lightboxes no longer have the “clone” error.
None of my lightboxes have an “X” for closing.
Yet they close anyway if you click outside the lightbox (fail).

The very important TOS (Terms of Service) lightbox is still failing as before.
It failed to open completely.
Had to change the name of the lightbox - no change in code - then it would open with the
.catch error checking. Then I was locked out for a few minutes.
When wix/corvid returned to “normal,” the TOS ligtbox failed to load yet again.
Eventually, playing “whack-a-mole” with the name change failed also.
Wix/Corvid just ignores the lines of code that ask for the TOS lightbox to open.

Looks like a prank with a hidden router file .

Some really fishy stuff on the intranet.

Hi @brainstorrrm :

  1. As far as I recall, lightboxes have always closed when the user clicks outside the lightbox. This is a product decision. I agree that it may not be ideal, and I encourage you to submit a feature request to change this behavior. You could in theory also catch the lightbox closure (if the resolved Promise’s returned data is empty) then perform some action or even throw an error, which would route the code to the .catch() block.

  2. In this case, if you want to force the user to agree to Terms of Service, you’d probably be better off using a modal dialog box. We have an openModal( ) API for that which hopefully will meet your needs.

  3. I’d like to see the issues you’re having with your TOS lightbox; can you please send the URL for the page that calls the lightbox so I can investigate further?
    Thanks.

@chaim-kram PM me.

@brainstorrrm Send me the URL of your site; I can use that to contact you offline. (The PM feature seems to have been removed from the Corvid Forum… )

@chaim-kram Well - turn ON the PM feature and PM me.

@brainstorrrm FWIW I spoke to someone here about the PM feature and he is considering how we can securely establish off-line communications with our users. In the meantime, please provide me with another channel and I can contact you that way. (If you post your site URL I can work with that.) Thanks.