https://bugzilla.mozilla.org/show_bug.cgi?id=1397928
Was looking into that _POSIX_PATH_MAX/NAME_MAX issue earlier because it didn't make a lot of sense and I was thinking of other approaches besides char arrays, and I wanted to make sure it didn't cause problems after they did it. Turns out that one commit after this was added, Mozilla determined the code I was working on fixing to be dead code as of Firefox 58. I don't know if it's dead code in Pale Moon as well, but given that it compiles fine without it and I can't find any other references to szExeFile in the IPC code, that seems like a safe bet.
Besides, I determined config/pathsub.c already seems to do what this code looks like it's trying to do, and implements the solution of just defining NAME_MAX to 256 and having done with it that I nearly adopted after realizing that even OS/2 and BeOS, let alone Unix/Linux systems, all basically use that value and there's just disagreement on which system header to check for it.
This is mostly ifdefs, but as you can see, Solaris is actually a lot like Linux. They're both more SysV than BSD at core, and most of the differences have more to do with Solaris not using glibc than anything else.
I still need to audit a lot of these changes and understand why they're needed and what the alternative approaches are. After this patch, most of the core functionality needed to build Solaris is here.
When Mozilla implemented this initially, only Windows 8 existed.
Because of the strict equal check, 8.1 and 10 didn't get HWA over RDP
while they are perfectly capable of doing so with RemoteFX. This change
allows any version of Windows from 8.0 onwards to use HWA over RDP.
This creates a number of stubs and leaves some surrounding code that may be irrelevant (eg. recorded time stamps, status variables).
Stub resolution/removal should be a follow-up to this.
Currently, EventListenerManager calls WidgetEvent::PreventDefault() when the status is nsEventStatus_eConsumeNoDefault.
That causes an unexpected state of events.
To solve this, WidgetEvent should do nothing when it's not cancelable but PreventDefault() is called.
Issue #55
part 1 - Add transitioncancel event handler
part 2 - Add ontransitioncancel EventHandler to WebIDL
part 3 - Add member of active time to ComputedTiming
Although this is only known to affect buttons with builtin child widgets, it is difficult to audit all GTK widgets for similar situations, and so the same defense is applied to all widgets.
