Bugzilla – Full Text Bug Listing
|
Description
Leo Ufimtsev
Investigating. A "disadvantage" of SWT's popularity is that we have to assume that there's always a user for any API that was published. To find concrete cases, use searches like these: https://www.google.com/search?q=site%3Agithub.com+"org.eclipse.swt.browser.BrowserFunction"+return https://www.google.com/search?q=site%3Agit.eclipse.org+"org.eclipse.swt.browser.BrowserFunction"+return http://www.massapi.com/class/org/eclipse/swt/browser/BrowserFunction.html E.g. this one looks like an actual user of this functionality (note that locationtech.org is an Eclipse Foundation Working Group): https://github.com/locationtech/geoff/blob/master/plugins/org.locationtech.geoff.ui.swt/src/org/locationtech/geoff/ui/swt/GeoMapComposite.java#L143 (In reply to Markus Keller from comment #2) > A "disadvantage" of SWT's popularity is that we have to assume that there's > always a user for any API that was published. > > To find concrete cases, use searches like these: > https://www.google.com/search?q=site%3Agithub.com+"org.eclipse.swt.browser. > BrowserFunction"+return Interesting, I didn't think of this mechanism. Thank you for sharing. > https://www.google.com/search?q=site%3Agit.eclipse.org+"org.eclipse.swt. > browser.BrowserFunction"+return > http://www.massapi.com/class/org/eclipse/swt/browser/BrowserFunction.html > > E.g. this one looks like an actual user of this functionality (note that > locationtech.org is an Eclipse Foundation Working Group): > > https://github.com/locationtech/geoff/blob/master/plugins/org.locationtech. > geoff.ui.swt/src/org/locationtech/geoff/ui/swt/GeoMapComposite.java#L143 Thank you for taking the time to find some use cases. Much appreciated. This is helpful. I was searching around for BrowserFunction 'return' use cases in the eclipse git repos: https://git.eclipse.org/c/ Thus far I found that Nebular's Richtext editor is build via the Browser widget with BrowserFunction callback mechanisms. It may be a potential valid use case as well. New Gerrit change created: https://git.eclipse.org/r/106164 New Gerrit change created: https://git.eclipse.org/r/110256 Need SWT natives to be build with RHEL 7.4 before I can merge. Seems like it'll be next week ish. Tracked in: Bug 476642 – Start building natives @eclipse.org infra https://bugs.eclipse.org/bugs/show_bug.cgi?id=476642 Gerrit change https://git.eclipse.org/r/110256 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=8009c3b86dee4f50191b785f9c121ef5cdd24746 Hi Leo, There are compilation errors while building the new library. Please see: https://hudson.eclipse.org/releng/view/SWT%20Natives/job/gtk_linux_x86/37/console https://hudson.eclipse.org/releng/view/SWT%20Natives/job/gtk_linux_x86_64/29/console The new library is not built due to compilation errors but currently the gtk build jobs don't fail due to this. Rest of the libraries are built and committed as usual. But, once the new library is built successfully, the library count has to changed in check_fragment_libraries in buildSWT.xml. Without this change the build will fail. (In reply to Lakshmi Shanmugam from comment #9) > The new library is not built due to compilation errors but currently the gtk > build jobs don't fail due to this. Rest of the libraries are built and > committed as usual. > > But, once the new library is built successfully, the library count has to > changed in check_fragment_libraries in buildSWT.xml. Without this change the > build will fail. Also, I think some changes will be required in the Hudson build jobs to pick the library on ppc64(le) as it is placed under another directory. New Gerrit change created: https://git.eclipse.org/r/112743 Gerrit change https://git.eclipse.org/r/112743 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=95367b1fc23f9ea8ca08752b75ba1cefe9ca838d Hi Alex, Leo, Can we make a check if the webkit package required for building the new library is available or not before trying to build it? Similar to the check we do for Cairo or AWT. Having such a check will be useful to build SWT gtk libs on setups which don't have the required package. (In reply to Lakshmi Shanmugam from comment #13) > Hi Alex, Leo, > Can we make a check if the webkit package required for building the new > library is available or not before trying to build it? > Similar to the check we do for Cairo or AWT. > Having such a check will be useful to build SWT gtk libs on setups which > don't have the required package. Yes, I can implement such a guard. (In reply to Leo Ufimtsev from comment #14) > (In reply to Lakshmi Shanmugam from comment #13) > > Hi Alex, Leo, > > Can we make a check if the webkit package required for building the new > > library is available or not before trying to build it? > > Similar to the check we do for Cairo or AWT. > > Having such a check will be useful to build SWT gtk libs on setups which > > don't have the required package. > > Yes, I can implement such a guard. I'm not in favor of such guard. Most Linux users don't have webkit1(or won't have it on their next update) due to security issues with it thus having proper webkit2 is mandatory so we should look this webextension as crucial part of having proper browser implementaiton under linux. Leo, you used the new "planning" feature and set a deadline. I would appreciate to no use that unless there's a definition of what this means in our project. (In reply to Dani Megert from comment #16) > Leo, you used the new "planning" feature and set a deadline. I would > appreciate to no use that unless there's a definition of what this means in > our project. I see. Thanks for pointing out. The planning feature is not new, it's always been there but was only visible to users in the 'time tracking' group (of which I was a member). I've been using the timegroup tracking for well over a year to followup on tickets. (e.g add someone as a reviewer and then followup in a week). But in Bugzilla 5 it's now made public and everyone can see. I can see how this could be confusing to users who see the bug, so it looks like I'll have to find some other way to followup with tickets :-/. Oh well. (In reply to Leo Ufimtsev from comment #17) > (In reply to Dani Megert from comment #16) > > Leo, you used the new "planning" feature and set a deadline. I would > > appreciate to no use that unless there's a definition of what this means in > > our project. > > I see. Thanks for pointing out. > The planning feature is not new, it's always been there but was only visible > to users in the 'time tracking' group (of which I was a member). > I've been using the timegroup tracking for well over a year to followup on > tickets. (e.g add someone as a reviewer and then followup in a week). > But in Bugzilla 5 it's now made public and everyone can see. I can see how > this could be confusing to users who see the bug, so it looks like I'll have > to find some other way to followup with tickets :-/. Oh well. I'd actually like to hide that again. (In reply to Dani Megert from comment #18) > (In reply to Leo Ufimtsev from comment #17) > > (In reply to Dani Megert from comment #16) > > > Leo, you used the new "planning" feature and set a deadline. I would > > > appreciate to no use that unless there's a definition of what this means in > > > our project. > > > > I see. Thanks for pointing out. > > The planning feature is not new, it's always been there but was only visible > > to users in the 'time tracking' group (of which I was a member). > > I've been using the timegroup tracking for well over a year to followup on > > tickets. (e.g add someone as a reviewer and then followup in a week). > > But in Bugzilla 5 it's now made public and everyone can see. I can see how > > this could be confusing to users who see the bug, so it looks like I'll have > > to find some other way to followup with tickets :-/. Oh well. > > I'd actually like to hide that again. I'm in favor because we use target milestone as time frames. (In reply to Dani Megert from comment #18) > (In reply to Leo Ufimtsev from comment #17) > > (In reply to Dani Megert from comment #16) > > > Leo, you used the new "planning" feature and set a deadline. I would > > > appreciate to no use that unless there's a definition of what this means in > > > our project. > > > > I see. Thanks for pointing out. > > The planning feature is not new, it's always been there but was only visible > > to users in the 'time tracking' group (of which I was a member). > > I've been using the timegroup tracking for well over a year to followup on > > tickets. (e.g add someone as a reviewer and then followup in a week). > > But in Bugzilla 5 it's now made public and everyone can see. I can see how > > this could be confusing to users who see the bug, so it looks like I'll have > > to find some other way to followup with tickets :-/. Oh well. > > I'd actually like to hide that again. Would you please handle this in dedicated bz? Leo, is this bug done? Can we resolve it for M4 ? New Gerrit change created: https://git.eclipse.org/r/112843 Gerrit change https://git.eclipse.org/r/112843 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=046cce2c7c22bc552489d4d7870b7b1919930c67 New Gerrit change created: https://git.eclipse.org/r/112847 Gerrit change https://git.eclipse.org/r/112847 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=d3d082282785170b3c46bf628ba9427979d49640 (In reply to Alexander Kurtakov from comment #20) > Would you please handle this in dedicated bz? See bug 528132. Versioned Webextensions folder verified to work on todays's build: eclipse-SDK-I20171205-0800-, i.e, extension is extracted and loaded. Also note, the make_linux.mak now rm/rmdir old webkitextensionsXXXX folder form binary repo, as per logic here: https://git.eclipse.org/r/#/c/112843/1/bundles/org.eclipse.swt/Eclipse+SWT+PI/gtk/library/make_linux.mak Open tasks (In order of priority): [] Implement mechanism to extract webextensions folder when SWT is launched as part of Eclipse. (OSGI extraction mechanism) [] Warning printed on 32bit Linux builds. > webkitgtk_extension.c:280:4: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘gsize’ [-Wformat=] > g_error("Should only receive a single item in the tuple, but length is: %lu\n", g_variant_n_children(g_var_result)); > ^rs [] Don't build extension if webkit-extension pkg-config flags are not available. [] Request Webkitgtk developers to implement a mechanism to load extension directly instead of having to specify a folder. New Gerrit change created: https://git.eclipse.org/r/113021 New Gerrit change created: https://git.eclipse.org/r/113022 Gerrit change https://git.eclipse.org/r/113021 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=c0925b528e5ba379d83868fd67f1aff0e88be8de Gerrit change https://git.eclipse.org/r/113022 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=ccddf4d86de9b18c70f5ee874a6495a2eaeeed6d New Gerrit change created: https://git.eclipse.org/r/113030 New Gerrit change created: https://git.eclipse.org/r/113029 Gerrit change https://git.eclipse.org/r/113029 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=87ad67c89aea7399b495bc6b63cebc72115bed9c Gerrit change https://git.eclipse.org/r/113030 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=0998f3f4251de4c14b95810f9f5534eb46ad36e8 New Gerrit change created: https://git.eclipse.org/r/113031 Awaiting M4 release to submit/merge outstanding patches. New Gerrit change created: https://git.eclipse.org/r/113091 New Gerrit change created: https://git.eclipse.org/r/113092 Gerrit change https://git.eclipse.org/r/113091 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=9c55d07591d154b42f50854c7654c7e856ae1587 Gerrit change https://git.eclipse.org/r/113092 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=cf6eae19947ae022733790303bba743fdcc0af93 Gerrit change https://git.eclipse.org/r/113031 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=0b13ae7a288041245b030d0d11d81e0e61a5745f (In reply to Lakshmi Shanmugam from comment #13) > Hi Alex, Leo, > Can we make a check if the webkit package required for building the new > library is available or not before trying to build it? > Similar to the check we do for Cairo or AWT. > Having such a check will be useful to build SWT gtk libs on setups which > don't have the required package. Done in: https://git.eclipse.org/r/#/c/113031/ Feature implemented and (afaik) all outstanding issues were addressed. I'll verify in tomorrow's(ish) build. Verified against today's ibuild. As note: *) when SWT is ran as OSGI bundle, the extension is correctly extracted to ./configuration/org.eclipse.osgi/215/0/.cp/webkitextensions4845/libswt-webkit2extension-gtk-4845.so (And when swt is ran standalone, then they are extracted to ~/.swt/...) *) 32bit compile warning fixed: https://hudson.eclipse.org/releng/view/SWT%20Natives/job/gtk_linux_x86/lastBuild/console *) webextension .so/dir are deleted by build script before new build. Have to remove debug print statments from WebkitGTK.java and Library.java. (Will do shortly). New Gerrit change created: https://git.eclipse.org/r/113185 Gerrit change https://git.eclipse.org/r/113185 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=9f13fe28a434720b783cb6e1681537bbe5331077 Debug messages removed. We're good to go. As per previous comment, verified on today's IBuild. Leo, the Gerrit fails with compilation error:
[javac] Compiling 446 source files
/opt/public/hipp/homes/genie.platform/workspace/tmp/check.compile.master/build/org/eclipse/swt/browser/WebkitGDBus.java:92: error: cannot find symbol
if (WebKitGTK.SWT_WEBKIT_DEBUG_MSGS) System.out.println("SWT_WEBKIT: Webkit GDBus is being initialized with id: " + uniqueId);
^
symbol: variable SWT_WEBKIT_DEBUG_MSGS
location: class WebKitGTK
/opt/public/hipp/homes/genie.platform/workspace/tmp/check.compile.master/build/org/eclipse/swt/browser/WebkitGDBus.java:92: error: illegal start of type
if (WebKitGTK.SWT_WEBKIT_DEBUG_MSGS) System.out.println("SWT_WEBKIT: Webkit GDBus is being initialized with id: " + uniqueId);
^
https://hudson.eclipse.org/platform/job/eclipse.platform.swt-Gerrit/5755/console
https://hudson.eclipse.org/platform/job/eclipse.platform.swt-Gerrit/5757/console
(In reply to Andrey Loskutov from comment #50) > Leo, the Gerrit fails with compilation error: > > [javac] Compiling 446 source files > /opt/public/hipp/homes/genie.platform/workspace/tmp/check.compile.master/ > build/org/eclipse/swt/browser/WebkitGDBus.java:92: error: cannot find symbol > if (WebKitGTK.SWT_WEBKIT_DEBUG_MSGS) System.out.println("SWT_WEBKIT: > Webkit GDBus is being initialized with id: " + uniqueId); > ^ > symbol: variable SWT_WEBKIT_DEBUG_MSGS > location: class WebKitGTK > /opt/public/hipp/homes/genie.platform/workspace/tmp/check.compile.master/ > build/org/eclipse/swt/browser/WebkitGDBus.java:92: error: illegal start of > type > if (WebKitGTK.SWT_WEBKIT_DEBUG_MSGS) System.out.println("SWT_WEBKIT: > Webkit GDBus is being initialized with id: " + uniqueId); > ^ > > https://hudson.eclipse.org/platform/job/eclipse.platform.swt-Gerrit/5755/ > console > https://hudson.eclipse.org/platform/job/eclipse.platform.swt-Gerrit/5757/ > console Sorry, my bad. Was too hasty to merge previous patch. Will fix shortly. (In reply to Andrey Loskutov from comment #50) > https://hudson.eclipse.org/platform/job/eclipse.platform.swt-Gerrit/5757/ > console Fixed. Sorry for trouble caused. (In reply to Leo Ufimtsev from comment #52) > (In reply to Andrey Loskutov from comment #50) > > https://hudson.eclipse.org/platform/job/eclipse.platform.swt-Gerrit/5757/ > > console > > Fixed. Sorry for trouble caused. Not sure. Now I see the crash in webkit code: https://hudson.eclipse.org/platform/job/eclipse.platform.swt-Gerrit/5759/console [INFO] Running org.eclipse.swt.tests.junit.Test_org_eclipse_swt_browser_Browser Running Test_org_eclipse_swt_browser_Browser#test_TitleListener_removeWithNullArg Running Test_org_eclipse_swt_browser_Browser#test_getText_html Running Test_org_eclipse_swt_browser_Browser#test_LocationListener_then_ProgressListener Running Test_org_eclipse_swt_browser_Browser#test_OpenWindowListener_closeShell Running Test_org_eclipse_swt_browser_Browser#test_LocationListener_addAndRemove Running Test_org_eclipse_swt_browser_Browser#test_forward Running Test_org_eclipse_swt_browser_Browser#test_ProgressListener_addAndRemove Running Test_org_eclipse_swt_browser_Browser#test_CloseWindowListener_removeWithNullArg Running Test_org_eclipse_swt_browser_Browser#test_TitleListener_addAndRemove Running Test_org_eclipse_swt_browser_Browser#test_VisibilityWindowListener_eventSize Running Test_org_eclipse_swt_browser_Browser#test_OpenWindowListener_open_ChildPopup # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f05250c5ddd, pid=26887, tid=0x00007f05eb676700 # # JRE version: Java(TM) SE Runtime Environment (8.0_131-b11) (build 1.8.0_131-b11) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.131-b11 mixed mode linux-amd64 compressed oops) # Problematic frame: # C [libwebkitgtk-3.0.so.0+0x44eddd] # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /opt/public/hipp/homes/genie.platform/workspace/eclipse.platform.swt-Gerrit/hs_err_pid26887.log (In reply to Andrey Loskutov from comment #53) > (In reply to Leo Ufimtsev from comment #52) > > (In reply to Andrey Loskutov from comment #50) > > > https://hudson.eclipse.org/platform/job/eclipse.platform.swt-Gerrit/5757/ > > > console > > > > Fixed. Sorry for trouble caused. > > Not sure. Now I see the crash in webkit code: > https://hudson.eclipse.org/platform/job/eclipse.platform.swt-Gerrit/5759/ > console This one is webkit1's unstable behavior. It tends to crash from time to time. You can try to re-start the build, usually after 1-2 extra attempts it works. In an eclipse, you can try to re-start your eclipse and then the tests usually pass again (or restart server?). We hope to have the issue resolved once webkit2 is default on the test servers. (please follow webkit2 port bug to track). |