Details
-
Type:
Task
-
Status: Closed (View Workflow)
-
Priority:
Major
-
Resolution: Done
-
Affects Version/s: None
-
Fix Version/s: 9.1.10 Major Release
-
Labels:None
-
Story Points:2
-
Epic Link:
-
Sprint:Fall 5 2022 Oct 24
Description
Both saving a track, saving a session, and exporting weblinks can occur where the file is saved without a file extension.
When attempting to save a track IGB shows an error:
"Problem saving file. More information about what went wrong may be available in the Console. To get help, visit the IGB Help Page."
Attempting to save a session automatically suggests a file name including a file extension. But if the user submits a name without a user-typed file extension the file does not save properly.
for both, a file extension is chosen in the file chooser but it is not being applied to the file upon saving.
Saving images and exporting bookmarks works normally.
This problem does not occur on 9.1.8.
Tested on Linux Ubuntu 20: 9.1.10 and 9.1.8
Attachments
Issue Links
- relates to
-
IGBF-2654 Fix: 'replace' action while saving file
-
- Closed
-
Activity
Note on difference between Linux and Mac behavior:
When saving a track on Mac the save window automatically populates the name field with the default text "untitled.bed".
On Linux the save window starts with a blank name field.
Update, also affects weblinks. (and PAXML files in ProtAnnot App)
I think the problem is that the file extension is not being added to the saved file (unclear why this is specific to Linux), so the saved file is initiated as "file" instead of "file.bed". However, when IGB attempts to write the data it is probably trying to write it to "file.bed" and this is leading to the null.
Ultimately it is unclear why Linux is not adding the file extension correctly. Adding the extension by default should fix this issue.
Until we can determine why Linux is behaving differently then Windows/Mac I have separated the file extension logic based on the operating system.
Commit: https://bitbucket.org/nfreese/nowlanfork-igb/commits/48757f7b95d689cfd0e7ed9a4fc897db187c16cf
Side note: I wondered why there was an additional extension added on to the file in FileChooserUtil.java. This was the cause of several problems on Mac and Windows. My guess is that the developer was working on Linux and that's why the extension was added. So there could be differences in how the FileChooser.java class works with the native file choosers on the different operating systems. For example, we have also noticed some minor differences on Windows where the native file chooser extension dropdown menu lists the extension twice (.bed and *.bed) whereas on Mac this issue does not appear.
Suggestion: google search to find ways that developers have detected host computer OS in Java to check for regular expressions "gotchas":
Examples:
Spreadsheet comparing file saving behaviors on Linux:
https://docs.google.com/spreadsheets/d/19_eLW93H4qYc9VRrVntCEenA60vvI5bWgLeGeHm9KoQ/edit?usp=sharing
- Merged. Installers are building.
- Installers built.
- Notarized master.dmg (Apple installer) with:
xcrun altool --notarize-app --primary-bundle-id "2022-11-03-igb-9.1.10" -u [redacted] --asc-provider [redacted] -p [redacted] --file master.dmg
xcrun stapler staple master.dmg
- Updated notarized master.dmg to team repository Downloads section
The issue is due to the JavaFX FileChooser not adding the extensions to the file in the same way that Windows and Mac native filechoosers do. From what I can tell from various blog posts this behavior is consistent and not due to the FileChooser being implemented incorrectly. Therefore, I have used logic that was present in BookmarkManagerView.java and added it to WebLinksView.java, SaveSessionAction.java, and AbstractExportFileAction.java that looks to see if the extension is present in the save file path, and if not, the extension is added. This corrects the issue where the extension was not appearing on Linux. Note that I did not apply the same logic to ExportDialog.java as the image FileChooser has some different and additional logic.
10:37:55.039 WARN c.a.genometry.util.ErrorHandler - null
java.lang.NullPointerException: null
at com.affymetrix.igb.action.ExportFileAction.exportFile(ExportFileAction.java:68) ~[igb-9.1.10.jar:na]
at com.affymetrix.igb.action.AbstractExportFileAction.saveAsFile(AbstractExportFileAction.java:141) [igb-9.1.10.jar:na]
at com.affymetrix.igb.action.AbstractExportFileAction.actionPerformed(AbstractExportFileAction.java:87) [igb-9.1.10.jar:na]
at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022) ~[na:1.8.0_332]
at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348) ~[na:1.8.0_332]
at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402) ~[na:1.8.0_332]
at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259) ~[na:1.8.0_332]
at javax.swing.AbstractButton.doClick(AbstractButton.java:376) ~[na:1.8.0_332]
at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:842) ~[na:1.8.0_332]
at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:886) ~[na:1.8.0_332]
at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:289) ~[na:1.8.0_332]
at java.awt.Component.processMouseEvent(Component.java:6539) ~[na:1.8.0_332]
at javax.swing.JComponent.processMouseEvent(JComponent.java:3324) ~[na:1.8.0_332]
at java.awt.Component.processEvent(Component.java:6304) ~[na:1.8.0_332]
at java.awt.Container.processEvent(Container.java:2239) ~[na:1.8.0_332]
at java.awt.Component.dispatchEventImpl(Component.java:4889) ~[na:1.8.0_332]
at java.awt.Container.dispatchEventImpl(Container.java:2297) ~[na:1.8.0_332]
at java.awt.Component.dispatchEvent(Component.java:4711) ~[na:1.8.0_332]
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4904) ~[na:1.8.0_332]
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4535) ~[na:1.8.0_332]
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4476) ~[na:1.8.0_332]
at java.awt.Container.dispatchEventImpl(Container.java:2283) ~[na:1.8.0_332]
at java.awt.Window.dispatchEventImpl(Window.java:2746) ~[na:1.8.0_332]
at java.awt.Component.dispatchEvent(Component.java:4711) ~[na:1.8.0_332]
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:760) ~[na:1.8.0_332]
at java.awt.EventQueue.access$500(EventQueue.java:97) ~[na:1.8.0_332]
at java.awt.EventQueue$3.run(EventQueue.java:709) ~[na:1.8.0_332]
at java.awt.EventQueue$3.run(EventQueue.java:703) ~[na:1.8.0_332]
at java.security.AccessController.doPrivileged(Native Method) ~[na:1.8.0_332]
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74) ~[na:1.8.0_332]
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:84) ~[na:1.8.0_332]
at java.awt.EventQueue$4.run(EventQueue.java:733) ~[na:1.8.0_332]
at java.awt.EventQueue$4.run(EventQueue.java:731) ~[na:1.8.0_332]
at java.security.AccessController.doPrivileged(Native Method) ~[na:1.8.0_332]
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74) ~[na:1.8.0_332]
at java.awt.EventQueue.dispatchEvent(EventQueue.java:730) ~[na:1.8.0_332]
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205) ~[na:1.8.0_332]
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) ~[na:1.8.0_332]
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) ~[na:1.8.0_332]
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) ~[na:1.8.0_332]
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) ~[na:1.8.0_332]
at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) ~[na:1.8.0_332]