Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    [BUG] Excel export crashes Chrome/Edge

    Exporting an excel of about 450kb in Chrome/Edge causes the browser memory usage to shoot up to 3.5~5 gigs often resulting in a browser crash.
    Everything works fine in Firefox.


    The issues has been replicated in 12.1p 2021-04-162, on Windows 10 both on dev and prod.
    We tested on a clean browser with no plugins on compiled code (no super dev or dev tool of sort).
    The resulting CSV file has 386 rows and 289 columns

    Here the code to replicate the issue:

    Code:
    @Override
    public void onModuleLoad()
    {
    VLayout layout = new VLayout();
    RootPanel.get().add(layout);
    
    Button button = new Button("add");
    button.addClickHandler(this::buttonClickHandler);
    layout.addMember(button);
    }
    
    private void buttonClickHandler(ClickEvent clickevent1)
    {
    DSRequest dsRequestProperties = new DSRequest();
    dsRequestProperties.setExportAs(ExportFormat.CSV);
    dsRequestProperties.setExportDisplay(ExportDisplay.DOWNLOAD);
    dsRequestProperties.setUseStrictJSON(true);
    Object[] data = IntStream.range(0, 386)
    .mapToObj(id -> {
    final Map<String, Object> res = new HashMap<>();
    res.put("id", id);
    res.put("name", "LONG_LONG_LONG_UNIT_NAME");
    res.put("total", 0f);
    IntStream.range(0, 288).forEach(i -> res.put("interval_" + i, i * 10));
    return res;
    })
    .toArray();
    DataSource.exportClientDataStatic(data, dsRequestProperties);
    }
    Last edited by Isomorphic; 21 May 2021, 18:43.

    #2
    (We've corrected your code to match your description, so that 386 records are present. 300 records did not reproduce the issue for us.)

    We see the issue with Chrome 90.0.4430.212 on Windows 10, but there is no problem with the same version of Chrome on Windows 8.1, or on MacOS Catalina, so it could be a Windows 10 bug if it isn't a Chromium bug. We didn't see any existing bug logged against Chromium for this issue.

    It turns out that the problem only seems to affect hidden frame transport, which is used by default for DataSource.exportClientData(), so we've made some changes to SC/SGWT 12.1+ so that you can set xhr transport on the export, and that seems to work around the problem. This fix will be the nightly builds dated 2021-05-22 and beyond.

    In your code above, add the following line after setUseStringJSON():
    Code:
     dsRequestProperties.setTransport(RPCTransport.XMLHTTPREQUEST);
    Note that we're having you add this manually, rather than making it the default for export, because we believe the underlying browser/OS issue should be resolved in the near future.

    Comment


      #3
      We did some tests internally and this is a good stop-gap for us.

      Is there any way to enable the change the xhr transport globally or we need to add that line everywhere we have an excel export?

      Comment


        #4
        We didn't put in a facility to do something like change the transport specifically all exports, because, of course, there's no way to anticipate the next thing that is going to break in the browser platform..

        You could:

        1. run all your exports through a common function, which might be useful for defaulting other things (like a filename if it's not specified)

        or

        2. if you have a common transformRequest override on all of your DataSources, you could detect that the operation is an export and switch the transport there

        Comment


          #5
          We are experiencing the same issue on ListGrid.exportClientData, with that export even changing the RPCTransport we still experience the browser crashing.

          Are we doing something wrong, or the patch only covers data exported via DataSource.exportClientDataStatic?

          Comment


            #6
            The expectation is that this would work for listGrid.exportClientData as well as the static DataSource method. It looks like the specified transport may not be being respected as it should in the ListGrid code flow. We have a developer taking a look and will follow up with more information next week

            Just for a quick sanity check: can we confirm which build you're seeing this behavior on? If it's not the most recent build, please do try with the latest nightly just to make sure we're looking at the same code. Thank you.

            Thanks
            Isomorphic Software

            Comment


              #7
              This issue (where the explicit 'xmlHTTPRequest' transport is not respected for listGrid.exportClientData) is now resolved.
              Please try the next nightly build, dated July 21 or above

              Regards
              Isomorphic Software

              Comment

              Working...
              X