isaak654
commented
2 years ago I can confirm the Vivaldi issue also with Plus 1.0.17 (reproduced with any online PDF file):
Note: It looks the same as the old #930 issue.
At that time, it was fixed with this code (no longer working for recent Vivaldi builds): https://github.com/sandboxie-plus/Sandboxie/commit/712617c13cf91c45f3271779977ea423b3250485#diff-60bf43005a5ae1c852835126db27eabf6130844c67f51abad8c8d471c4c791e8
You may not want to ditch the old fix altogether.
DavidXanatos
2022-10-04 - This is the second reply I received from the Vivaldi developer when I suggested the implication of the "Enable Internal PDF Viewer" Vivaldi setting:
> I am not aware that we have made any changes to the default of the "plugins.always_open_pdf_externally" preference (which is false, meaning use the internal PDF viewer).
>
> One thing that you might want to check is how you handle the Chromium process spawning (you seem to do a bit of deep manipulation of process launches), since Chromium is spawning a lot of processes per tab. Additionally, Vivaldi's GUI is a HTML/Javascript document embedding the tabs, running in a separate process. It is conceivable that this adds more process spawning layers than your system expects. If there is a problem with multiple level spawning, such as for nested frames, you might see issues in other browsers, too, for such documents
>
> Your screenshots indicate that the GUI is still running, which suggests that any process problems happen in one of the child processes. You might want to log command lines for each process to see which one is failing.
>
> Note that you can use the standard Chromium logging command line arguments, and for debugging there is also "--disable-vivaldi" which will enable the standard Chromium GUI, and disable Vivaldi-specific code paths. This could help you look for internal logic differences.
In this reply, it was implied that Vivaldi's GUI may need special treatment in Sandboxie, so @DavidXanatos may be interested to look again at this issue.
2022-10-06 - Third reply from the Vivaldi developer:
> There is an archive of old builds at [1]https://vivaldi.com/download/archive/?platform=win
>
> Just in case, check whether you use the 32 or 64 bit versions, on Win64 the 64 bit version is recommended.
>
> Note that you can install multiple Vivaldi installs (including various versions) in parallel using the Standalone choice in the installer, in addition to the global for the user, or the system-wide one. Make sure you disable updates, unless you plan to enable that (each install with update runs its own update process).
>
> You can keep up to date about new snapshots at [2]https://vivaldi.com/blog/desktop/releases/
>
> --disable-vivaldi may not disable everything we changed, but it shuts off most of the places where we changed logic, which is needed for many of the unit tests to work.
>
> If you really want to dig deep, the source bundles are available at [3]https://vivaldi.com/source/ ; they don't include the JS GUI code, but that can be copied into the proper location from a corresponding version.
2022-10-07 - In an internal test, the first Vivaldi build with this issue is [Vivaldi.5.2.2623.18.x64.exe](https://downloads.vivaldi.com/stable/Vivaldi.5.2.2623.18.x64.exe), while [Vivaldi.5.1.2567.73.x64.exe](https://downloads.vivaldi.com/stable/Vivaldi.5.1.2567.73.x64.exe) is the last good one. Before that, I had to set a software restriction policy (SRP) in order to block the following path: `C:\Users\%Username%\AppData\Local\Temp\VivaldiUpdate-*\*\*.exe`
2022-10-08 - A fix was provided in c60871d46c2eaefa4ab07194d856826e0f5f7e6b and 1e126403d0f86cc47c508841d333f53578e5bac2 - according to David, this is due to a compiler optimization flag in Vivaldi
2022-10-09 - I updated the Vivaldi Team by providing the Sandboxie commits above, this is the message I received in return:
> In case you want to better locate the possible regression point:
>
> Last 5.2 snapshot release before Chromium 100: [1]https://vivaldi.com/blog/desktop/so-many-fixes-snapshot-2603-6/
>
> First 5.2 Snapshot after Chromium 100 update: [2]https://vivaldi.com/blog/desktop/underlying-mail-changes-vivaldi-browser-snapshot-2617-2/
This is the counter-reply from the Sandboxie lead developer:
> I think they did not change the function stub knowingly, I think they changed a compiler Optimizer option to favor smaller binaries and that resulted in the binary representation of that function to change. the function must look like `NTSTATUS some_name { return 1; }` in the code and presumably is chrome original
Counter-reply from the Vivaldi developer:
> After a quick skim of diffs I am unable to see anything major related to linking or optimization on Windows between the two versions.
>
> The major differences I noticed are 1) The clang version was changed from 14 to 15, this includes a modified linker, 2) C++ version from C+17 to C+20.
>
> There was no change in Windows SDK version (that was done for Chromium 104)
>
> Regarding optimizing, as far as I am aware Chrome is built using PGO, Vivaldi isn't currently. That might cause some differences. Vivaldi is using the default Official Build optimization, which is level 2.
>
> Re NTSTATUS, I am not able to discover what that might refer to, since there are 4500+ occurrences of that word in the source code. I will need more details.
Counter-reply from the Sandboxie lead developer:
> they changed the compiler major version, of course it may generate a slightly different code.
Counter-reply from the Vivaldi developer:
> Just to be clear: The new compiler and C++ language versions were upstream changes from Chromium.
Counter-reply from the Sandboxie lead developer:
> hmm... then Chrome should have the same issue unless they are using a newer dev branch than what Chrome releases as stable
Counter-reply from the Vivaldi developer:
> Unfortunately, I have no real idea what could be causing such a difference.
>
> The project file changes we have made are usually just adding our extra files and targets. or Vivaldi specific defines and such. Compilation, optimization, and linking should be mostly the same, with the mentioned difference that Chrome (and possibly some of the other browsers are, too) are optimized using PGO (based on profiling the executable).
>
> In cases such as this, I would start looking carefully at what is done differently when launching Chrome.exe/dlls and when launching Vivaldi.exe/dlls (note the name difference). In particular, I'd try to disable everything done differently for Vivaldi (in this case, except the different exe/DLL names, if that determines anything), or that is not done for Chrome.
>
> IIRC there has been no mention about normal webpages not working, which probably means the firewall is not involved in the issue.
>
> However, unless I am mistaken, the PDF code involves a lot of interprocess communication using IPC/Mojo to/between the Renderer and/or GPU processes. Problems in these could crash processes. Given that the both the Vivaldi GUI and the PDF viewer background in the tab are displayed OK, and the tab is not showing a dead bird, I would guess that a background process crashed, and reporting the command line of that process, if you can, might suggest where things go wrong.
Final reply from the Sandboxie lead developer:
> we have found the change in the stub function, adapted our hooking code accordingly and this has resolved the issue, and for now no further action on either side is required
NotepadPlusUser
What happened?
Vivaldi : version 5.2.2623.26 (Stable channel) (64-bit) Windows 10 : Windows 10 Version 21H1 (Build 19043.1586)
Sandboxie Classic : 5.55.15
Recent versions of Vivaldi will not open online PDFs ... for example https://www.ebu.co.uk/documents/results-data/2022/national-pairs/NatPairs2022.pdf
What results is an empty dark screen where the text should be. Outside Sandboxie PDF's are opened correctly. I can't rewind to an earlier version of Vivaldi as I keep getting force fed the latest version via automatic updates that I can't seem to turn off ... that is another problem but one I can live with.
I notice some months ago another poster reported a similar problem that was resolved with an update to SB. Hope someone can help. All the best.
Download link
Not relevant
To Reproduce
No response
Expected behavior
.
What is your Windows edition and version?
.
In which Windows account you have this problem?
Not relevant to my request.
Please mention any installed security software
.
What version of Sandboxie are you running?
.
Is it a regression?
No response
List of affected browsers
No response
In which sandbox type you have this problem?
I only reproduced it with Sandboxie Classic.
Where is the program located?
Not relevant to my request.
Can you reproduce this problem on an empty sandbox?
Not relevant to my request.
Did you previously enable some security policy settings outside Sandboxie?
No response
Crash dump
No response
Trace log
No response
Sandboxie.ini configuration
No response