Commit message (Collapse) | Author | Age | Lines | |
---|---|---|---|---|
* | Use a separate process to generate thumbnails only when multi-process mode ↵ | JustOff | 2018-10-27 | -1/+5 |
| | | | | is enabled | |||
* | Fix a test (#670) | wolfbeast | 2018-10-19 | -6/+0 |
| | ||||
* | Convert trinary to more explicit statement. | wolfbeast | 2018-07-26 | -3/+6 |
| | ||||
* | Fix #include and potentially undefined Capture.options object. | wolfbeast | 2018-07-26 | -2/+2 |
| | ||||
* | Use a fixed thumbnail placeholder for blank thumbs (failed to capture). | wolfbeast | 2018-07-25 | -5/+97 |
| | ||||
* | Use try/catch in PageThumbs writeData to deal with null data from caller. | wolfbeast | 2018-07-25 | -1/+9 |
| | | | | Quick fix for #670 | |||
* | On failure, save a dummy file from the background page thumb capture module. | wolfbeast | 2018-07-04 | -1/+6 |
| | | | | | | | | | If a background page thumbnail capture fails (e.g. due to too heavy scripting), we should write -something- to the thumbnail cache, because otherwise it will try again and again, which is problematic for bad trap pages, that even if the user has left the page never to return again, the thumbnail service may still try to capture, and fail. This resolves the only problem for us in #592. | |||
* | Add m-esr52 at 52.6.0 | Matt A. Tobin | 2018-02-02 | -0/+4302 |