Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. QWebEnginePage runJavaScript callback
Forum Updated to NodeBB v4.3 + New Features

QWebEnginePage runJavaScript callback

Scheduled Pinned Locked Moved Unsolved General and Desktop
13 Posts 3 Posters 2.8k Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • Christoph SchaeferC Offline
    Christoph SchaeferC Offline
    Christoph Schaefer
    wrote on last edited by Christoph Schaefer
    #1

    We had some seg faults in a QWebEnginePage::runJavaScript callback. I tracked it down to an invalid QWebEnginePage pointer.
    Example:

    page()->runJavaScript("// JavaScript code here",
                                          QWebEngineScript::ApplicationWorld,
                                          [this](const QVariant& data) {
    page()->scrollPosition(); // sometimes seg fault because page() returns an invalid pointer
    }
    

    Why is the page which triggers the callback invalid in its own callback? Is there a way to make this code safe?

    jsulmJ JonBJ 2 Replies Last reply
    0
    • Christoph SchaeferC Christoph Schaefer

      We had some seg faults in a QWebEnginePage::runJavaScript callback. I tracked it down to an invalid QWebEnginePage pointer.
      Example:

      page()->runJavaScript("// JavaScript code here",
                                            QWebEngineScript::ApplicationWorld,
                                            [this](const QVariant& data) {
      page()->scrollPosition(); // sometimes seg fault because page() returns an invalid pointer
      }
      

      Why is the page which triggers the callback invalid in its own callback? Is there a way to make this code safe?

      jsulmJ Offline
      jsulmJ Offline
      jsulm
      Lifetime Qt Champion
      wrote on last edited by jsulm
      #2

      @Christoph-Schaefer said in QWebEnginePage runJavaScript callback:

      Is there a way to make this code safe?

      Check the pointer before dereferencing it.
      Also what is page() here?

      https://forum.qt.io/topic/113070/qt-code-of-conduct

      1 Reply Last reply
      0
      • Christoph SchaeferC Christoph Schaefer

        We had some seg faults in a QWebEnginePage::runJavaScript callback. I tracked it down to an invalid QWebEnginePage pointer.
        Example:

        page()->runJavaScript("// JavaScript code here",
                                              QWebEngineScript::ApplicationWorld,
                                              [this](const QVariant& data) {
        page()->scrollPosition(); // sometimes seg fault because page() returns an invalid pointer
        }
        

        Why is the page which triggers the callback invalid in its own callback? Is there a way to make this code safe?

        JonBJ Offline
        JonBJ Offline
        JonB
        wrote on last edited by
        #3

        @Christoph-Schaefer
        Have you verified (you may have done so) that in your callback it is definitely page() which is seg faulting? Are you sure it is not the scrollPosition() which is faulting (e.g. because you are trying to call it at the wrong time)?

        Christoph SchaeferC 1 Reply Last reply
        0
        • Christoph SchaeferC Offline
          Christoph SchaeferC Offline
          Christoph Schaefer
          wrote on last edited by
          #4

          The this pointer is a QWebEngineView:

          QWebEngineView* v = new  QWebEngineView();
          v->page()->runJavaScript("// JavaScript code here",
                                                QWebEngineScript::ApplicationWorld,
                                                [v](const QVariant& data) {
          v->page()->scrollPosition(); // sometimes seg fault because page() returns an invalid pointer
          }
          

          I ask this question because I am not sure if I do something wrong if I have to check the pointer. For me it is unexpected that Qt offers a method

          void QWebEnginePage::runJavaScript(const QString &scriptSource, quint32 worldId, const QWebEngineCallback<const QVariant &> &resultCallback)
          

          and inside the resultCallback the page in which the JavaScript was executed sometimes doesn't exist anymore. But if you say that's the intended behavior, I close the question. Thank you!

          jsulmJ 1 Reply Last reply
          0
          • Christoph SchaeferC Christoph Schaefer

            The this pointer is a QWebEngineView:

            QWebEngineView* v = new  QWebEngineView();
            v->page()->runJavaScript("// JavaScript code here",
                                                  QWebEngineScript::ApplicationWorld,
                                                  [v](const QVariant& data) {
            v->page()->scrollPosition(); // sometimes seg fault because page() returns an invalid pointer
            }
            

            I ask this question because I am not sure if I do something wrong if I have to check the pointer. For me it is unexpected that Qt offers a method

            void QWebEnginePage::runJavaScript(const QString &scriptSource, quint32 worldId, const QWebEngineCallback<const QVariant &> &resultCallback)
            

            and inside the resultCallback the page in which the JavaScript was executed sometimes doesn't exist anymore. But if you say that's the intended behavior, I close the question. Thank you!

            jsulmJ Offline
            jsulmJ Offline
            jsulm
            Lifetime Qt Champion
            wrote on last edited by
            #5

            @Christoph-Schaefer I don't know whether this is intended behaviour. Could be a bug (check Qt bug-tracker). Or maybe script couldn't be executed correctly and the page was invalidated?

            https://forum.qt.io/topic/113070/qt-code-of-conduct

            1 Reply Last reply
            0
            • JonBJ JonB

              @Christoph-Schaefer
              Have you verified (you may have done so) that in your callback it is definitely page() which is seg faulting? Are you sure it is not the scrollPosition() which is faulting (e.g. because you are trying to call it at the wrong time)?

              Christoph SchaeferC Offline
              Christoph SchaeferC Offline
              Christoph Schaefer
              wrote on last edited by
              #6

              @JonB
              It is definitely page(). The code

              v->page();
              

              also seg faults.
              I can reproduce it when the JavaScript execution takes very long and the page is deleted while JavaScript is still running. By deleting the page, the JavaScript is aborted and triggers the resultCallback. In this case the page pointer is invallid.

              jsulmJ JonBJ 2 Replies Last reply
              0
              • Christoph SchaeferC Christoph Schaefer

                @JonB
                It is definitely page(). The code

                v->page();
                

                also seg faults.
                I can reproduce it when the JavaScript execution takes very long and the page is deleted while JavaScript is still running. By deleting the page, the JavaScript is aborted and triggers the resultCallback. In this case the page pointer is invallid.

                jsulmJ Offline
                jsulmJ Offline
                jsulm
                Lifetime Qt Champion
                wrote on last edited by jsulm
                #7

                @Christoph-Schaefer said in QWebEnginePage runJavaScript callback:

                v->page();

                If this segfaults then most probably v is invalid pointer

                https://forum.qt.io/topic/113070/qt-code-of-conduct

                Christoph SchaeferC 1 Reply Last reply
                0
                • Christoph SchaeferC Christoph Schaefer

                  @JonB
                  It is definitely page(). The code

                  v->page();
                  

                  also seg faults.
                  I can reproduce it when the JavaScript execution takes very long and the page is deleted while JavaScript is still running. By deleting the page, the JavaScript is aborted and triggers the resultCallback. In this case the page pointer is invallid.

                  JonBJ Offline
                  JonBJ Offline
                  JonB
                  wrote on last edited by JonB
                  #8

                  @Christoph-Schaefer

                  I can reproduce it when the JavaScript execution takes very long and the page is deleted while JavaScript is still running. By deleting the page, the JavaScript is aborted and triggers the resultCallback. In this case the page pointer is invallid.

                  And is this what is happening in your case?

                  Also, at least OOI, what is it that your JavaScript code actually does? You seem to be trying to query scrollPosition() very early (not that I'm saying that's the seg fault), though maybe you know what you are doing...

                  1 Reply Last reply
                  0
                  • jsulmJ jsulm

                    @Christoph-Schaefer said in QWebEnginePage runJavaScript callback:

                    v->page();

                    If this segfaults then most probably v is invalid pointer

                    Christoph SchaeferC Offline
                    Christoph SchaeferC Offline
                    Christoph Schaefer
                    wrote on last edited by
                    #9

                    @jsulm
                    v is valid. It is captured in the lambda. When I check if v is valid, I got a warning: 'v' pointer cannot be null in well-defined C++ code; pointer may be assumed to always convert to true.

                    jsulmJ 1 Reply Last reply
                    0
                    • Christoph SchaeferC Christoph Schaefer

                      @jsulm
                      v is valid. It is captured in the lambda. When I check if v is valid, I got a warning: 'v' pointer cannot be null in well-defined C++ code; pointer may be assumed to always convert to true.

                      jsulmJ Offline
                      jsulmJ Offline
                      jsulm
                      Lifetime Qt Champion
                      wrote on last edited by
                      #10

                      @Christoph-Schaefer Well, the pointer itself can still be valid but not the object it is pointing to (for example if it was deleted). Can you try to call something else on it v->...?

                      https://forum.qt.io/topic/113070/qt-code-of-conduct

                      Christoph SchaeferC 1 Reply Last reply
                      0
                      • jsulmJ jsulm

                        @Christoph-Schaefer Well, the pointer itself can still be valid but not the object it is pointing to (for example if it was deleted). Can you try to call something else on it v->...?

                        Christoph SchaeferC Offline
                        Christoph SchaeferC Offline
                        Christoph Schaefer
                        wrote on last edited by
                        #11

                        @jsulm said in QWebEnginePage runJavaScript callback:

                        @Christoph-Schaefer Well, the pointer itself can still be valid but not the object it is pointing to (for example if it was deleted). Can you try to call something else on it v->...?

                        That's it. The v pointer is valid but the entire QWebEngineView behind it is gone.

                        v->title();
                        

                        also crash.
                        Still, unexpectedly, Qt does not ensure that the sender and receiver exist in the runJavaScript callback.

                        jsulmJ 1 Reply Last reply
                        0
                        • Christoph SchaeferC Christoph Schaefer

                          @jsulm said in QWebEnginePage runJavaScript callback:

                          @Christoph-Schaefer Well, the pointer itself can still be valid but not the object it is pointing to (for example if it was deleted). Can you try to call something else on it v->...?

                          That's it. The v pointer is valid but the entire QWebEngineView behind it is gone.

                          v->title();
                          

                          also crash.
                          Still, unexpectedly, Qt does not ensure that the sender and receiver exist in the runJavaScript callback.

                          jsulmJ Offline
                          jsulmJ Offline
                          jsulm
                          Lifetime Qt Champion
                          wrote on last edited by
                          #12

                          @Christoph-Schaefer It's indeed strange behaviour. Could be a bug.

                          https://forum.qt.io/topic/113070/qt-code-of-conduct

                          1 Reply Last reply
                          0
                          • Christoph SchaeferC Offline
                            Christoph SchaeferC Offline
                            Christoph Schaefer
                            wrote on last edited by
                            #13

                            I reported a bug for this QTBUG-72816.

                            1 Reply Last reply
                            0

                            • Login

                            • Login or register to search.
                            • First post
                              Last post
                            0
                            • Categories
                            • Recent
                            • Tags
                            • Popular
                            • Users
                            • Groups
                            • Search
                            • Get Qt Extensions
                            • Unsolved