View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002016 | Spring engine | Lua | public | 2010-08-03 00:45 | 2010-08-04 23:58 |
| Reporter | smoth | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | won't fix | ||
| Product Version | 0.82.0+git | ||||
| Summary | 0002016: Lua widgets should not do anything beyond get info when disabled. | ||||
| Description | This oversight allows widgets to run commands and other game effecting bits of undesirable scripts. We had a discussion on #SY about this and I feel it merits further discussion and better protection. The way it stands in the current spring, this widget would hide the tooltip and resbar without the user even knowing. There are other more amusing things like rebinding commands etc but it is just an example. If the widget is set to disabled or disabled in the list it should not be doing ANYTHING. While this is not a major issue I would like to see it addressed some day. | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| Checked infolog.txt for Errors | |||||
|
|
When writing widgets you should know/learn how they work, how lua works in spring. That includes when which part of the code is run. See http://springrts.com/mantis/view.php?id=1756 "Spring can not be expected to sanitize every possible Lua-provided argument." - I'd argue the same way here. You can not expect that Spring has protection against every possible fool-up you can implement. (btw: The example is one of the worst. A not needed change of a setting to the same value every draw frame.) Engine doesn't know about widgets. Only widget handler does (if mod has one). So a useful mechanism would be that there is a call-out that the widget handler can use to indicat that "hey Spring, ignore all commands from now on". And one that reverts that. You can't decide that within the engine, because from engine's point for view Initialize() is just one single call-in. The widget handler loads widgets and calls Initialize() for the active ones during that one call-in. If you add and use such a mechanism in widget handler you have to fix may widgets as they setup many global variables outside functions (e.g. getting team/player/gaia id, timers, including other files). Another thing to consider: People writing widgets will have to learn that they can't use commands outside functions. That does not improve the situation. They have to learn anyway - the one way or the other. I'd say this is a non-issue. |
|
|
This is not technically possible from the engine's perspective. To find out whether a widget is disabled, its code chunk has to be executed, so that the GetInfo function can be called. As a result *any and all* code in the widget's global environment is run. If a widget author does not wrap that code in an "if (initialized) then ... end" control structure, it may alter Spring's state just like ordinary callins. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-08-03 00:45 | smoth | New Issue | |
| 2010-08-03 00:45 | smoth | File Added: widget.lua | |
| 2010-08-03 23:35 | SirMaverick | Note Added: 0005215 | |
| 2010-08-04 23:58 | Kloot | Note Added: 0005223 | |
| 2010-08-04 23:58 | Kloot | Status | new => closed |
| 2010-08-04 23:58 | Kloot | Resolution | open => won't fix |
