Functionality Bug: Help Window hangs the system

[devivy]

After I typed the help command, the window opened. When I tried to close it, it took me to the main window and the app just hung.

[soc-se-bot]

Team's Response

Hi tester, we seem to only be able to reproduce this issue on Mac and specifically when the app is fullscreen-ed. This issue might lie in the OS that you are using as our members using Windows cannot reproduce this error.

Note: We are asking in the forum for Prof's input to this matter, and will update later. For now, we have labelled it as NotInScope.

Update: We have decided to accept it as a bug, but with the Low severity. We hope we can convince you via five arguments that the app is still usable (hence not High according to the guidelines, it is a very rare occurrence and that it does not affect normal operations of the product (hence not Medium according to the guidelines). The guidelines are reproduced below for our reference. The link to our forum question can be found here.

1. Usability: We believe the app is still usable despite this issue as if there are any operations executed that change the data of the application before the interruption occurs, the data is saved. Please refer to the below screen recording where we perform an add operation, and then reproduce the bug reported by repeatedly performing help in fullscreen mode and closing the pop-up window. Furthermore the function of the 'help' command is still fulfilled as the user will obtain the link to the user guide.

video:https://raw.githubusercontent.com/nus-cs2103-AY2425S1/pe/master/files/4c0f1d71-71a5-4920-80ef-d296d01f9480.mp4

2. Frequency of Occurrence: Based on our extensive testing, we are unable to determine the exact number of times that this bug occurs. At times, it takes a handful of times opening and closing the help window, while others it takes 10-20 times. Even while deliberately trying to make this bug happen the chances of it occurring are low. Users likely will only need to open the help window once to view the user guide each time they require help (i.e. they would likely not be opening it more than once when they need help for the add command for example. After going to the link provided in the help window, we believe their issue will be resolved such that they do not need to close the help window and open it again immediately after, and multiple times over). As such there is a very low chance that a user will naturally encounter this bug while using the app.

3. Number of users affected: Since this bug can only affect those using MAC OS, which makes up a small minority of users, most users cannot be affected by this bug and the likelihood that a user is affected by this bug is even lower.

4. Inconvenience: While we do agree it is inconvenient, the app can be force quit and restarted with all the data still intact and changes made saved, as shown in the screen recording above.

5. Expectation of Dev Team to Resolve the Bug: As we believe the underlying issue lies with JavaFx on the Mac OS, its a long stretch to expect the Dev Team to fix an issue with JavaFx. We believe a more reasonable request (and therefore triage) would be to list it as a Known Issue on the UG, and inform the user of this limitation in fullscreen mode.

Note: We have extensively tested not just our application, but other teams' applications obtained via their respectively Github release pages. Every app we have tested so far has experienced this issue on a Mac OS machine. The number of times needed to repeat the opening and closing of the help window in fullscreen mode to replicate the issue also varies.

Thank you

Items for the Tester to Verify

❓ Issue severity

Team chose [severity.Low]
Originally [severity.High]

• I disagree

Reason for disagreement: Dear Dev team,

I respectfully disagree with the Low severity classification and would like to address each point:

• Usability: While data persistence is appreciated, an application hang requiring force-quit is by definition a critical usability issue. The fact that users must force-quit the application contradicts the Low severity criteria of "minor inconvenience only." Suggesting that obtaining the help link before a crash makes the feature "fulfilled" is like saying a car is usable if it randomly stalls as long as it got you partway to your destination.
• Frequency: Your testing reveals this occurs every 10-20 attempts, which is not "very rare" as required for Low severity. More importantly, it's 100% reproducible under specific conditions (MAC OS + fullscreen). Your assumption that users only need help documentation once is incorrect - users regularly reference help for different features during their learning curve.
• User Base Impact: The MAC OS user argument actually strengthens the severity case. Having a known crash trigger for an entire operating system's user base is a significant issue. We wouldn't classify a Windows-only crash as Low severity, and MAC users deserve the same consideration.
• Inconvenience: Force-quitting an application is not a reasonable workaround. It:
  • Interrupts user workflow
  • Risks unsaved changes
  • Erodes user trust
  • Creates a negative user experience
• Technical Source: The underlying cause (JavaFX on MAC OS) doesn't reduce its severity. From a user perspective, an application crash is an application crash, regardless of its technical origin. If we know it's a consistent issue across multiple applications, this makes it even more critical to properly document and classify.

This bug forces MAC users to choose between using fullscreen (a basic feature) and safely accessing help documentation (a crucial feature).

I would appreciate if it would be set as medium severity criteria because it is a major inconvenience for affected users under normal usage conditions.

I appreciate your commitment to document this in the User Guide as a known issue - that's definitely helpful for users. However, proper severity classification remains important for tracking and prioritization purposes.

Thank you for your detailed consideration of this issue.

---