Seems your desire to code Brave is for you not for the people using it. STOP closing topics without a resolution. If we took the time to key up problems or recommendations you could at least respond with a written response as to when the whatever will be addressed including a date of resolution. It’s time to be accountble and let’s get a voting leaderboard of enhancements like tab groupings that did nothing but take up space. Repairs always have top priority over enhancements. The users will vote modifications or features up or down rather than this haphazzard never knowing what’s getting done.
Topics that don’t receive any activity or replies for 30 days are automatically closed for inactivity.
Topics are sometimes closed manually by support team or mods for a variety of reasons.
Typically the flow here is that if there are issues that are not user specific (that is, they reproduce for a number of other users and they are not related to specific system setup/extensions/etc.), an issue will be opened on our Github for our developers to review and address when they are able. Note that you [anyone] are also welcome to submit a bug/issue on our Github directly as well.
Users already can vote on feature requests here in the Brave Feature Requests category. Support and devs do review and use these as general guidelines for seeing what users want in the browser. That said, it simply can’t be guaranteed that a feature request will be implemented. Further, even if it is something that we want/can/plan on implementing in the browser, we cannot make guarantees on when it will be implemented.
This is because software development is a complicated process. Features, fixes, additions, refactors get moved around, pushed back, pushed forward or sometimes outright canceled due to the frequently shifting priorities, requirements and developer bandwidth. This is true for all software development.
The Github Project board is a good resource to use to see where certain features are with respect to priority and status of work done.
As for your issue, you did not provide a ton of information to go off of and as such I’m not entirely clear on what you’re seeing.
If I understand correctly, you’re saying that if you have dark mode enabled – which I’m assuming you mean the Enable force dark for web contents – and you go to print a page, the print preview shows that it’s going to print the page background color as well, which would be black?
If that is correct, then this already happens. For example if I go to print this Wikipeida page in dark mode, the preview shows the page as white and will print white, as intended:
If I am not understanding the issue correctly, then we’ll need you to provide some additional details/information about your issue so we can better assist you.
And to amend, like this forum, it will try to print dark (using the forums own dark mode, no forced modes), but you can uncheck the background checkbox, and it makes it lighter on your toner/ink.
There are solutions to issues, and when there aren’t, patience is always a must.
Precisely true.
As for their original post which mentioned screenshots: There’s nothing you can do there, it’s a “screen” shot, so how it’s rendered on-screen is what the screen shot will contain. You can invert the colors in an image editor (but if it has faces of people it’ll look like a negative), or temporarily disable the websites dark mode for screenshots.
