# Bug not resolved

**URL:** <https://community.brave.app/t/bug-not-resolved/647961>\
**Category:** Mobile Support\
**Tags:** android\
**Created:** [January 9, 2026, 6:49am UTC](https://community.brave.app/t/bug-not-resolved/647961 "2026-01-09T06:49:32Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![thecs](https://avatars.discourse-cdn.com/v4/letter/t/a8b319/32.png) [@thecs](https://community.brave.app/u/thecs)\
**Post date:** [January 9, 2026, 6:49am UTC](https://community.brave.app/t/bug-not-resolved/647961/1 "2026-01-09T06:49:32Z")

</div>

# 

> [@Fake tab strip shows up](https://community.brave.app/t/fake-tab-strip-shows-up/645258):
>
> Description of the issue: Random, or most probably, the previous tab shows as a fake tab in the tab strip at the bottom. Sometimes, tabs opened in Incognito mode appear in the normal tab, which is really concerning. It is not clickable; as soon as I open up the whole tab view page, the fake tab strip disappears. Expected result: it should not show the fake tab Brave Version( check About Brave):1.84.133 Mobile Device details Android 11 Additional Information: It’s happening for more than 2…

@Mattches the above post is closed but the issue is still there

---

<div class="post-metadata">

**Author:** ![leh](https://avatars.discourse-cdn.com/v4/letter/l/3da27b/32.png) [@leh](https://community.brave.app/u/leh)\
**Post date:** [January 9, 2026, 8:38am UTC](https://community.brave.app/t/bug-not-resolved/647961/2 "2026-01-09T08:38:33Z")

</div>

Don’t know about the incognito part, but I can reproduce the fake tab strip on Brave beta 1.86.128.  
If you stay on a tab inside a group for 3 seconds or more, then open the tab switcher and switch to a single tab, the fake tab group strip will appear.  
You can see in my screen record.  
The 1st time, I stayed in a grouped tab for more than 3s, the bug occurred.  
The 2nd time (from 13s in the video), I stayed in a grouped tab for less than 3s, the bug didn’t occur.  
The 3rd time (from 20s in the video), I stayed in a grouped tab for more than 3s then switched to another grouped tab, stayed on this tab for less than 3s, the bug didn’t occur.

edit: This bug only happens if I use “Enable bottom navigation toolbar” in Settings \> Appearance.

---

<div class="post-metadata">

**Author:** ![289wk](https://avatars.discourse-cdn.com/v4/letter/2/439d5e/32.png) [@289wk](https://community.brave.app/u/289wk)\
**Post date:** [January 10, 2026, 11:54am UTC](https://community.brave.app/t/bug-not-resolved/647961/3 "2026-01-10T11:54:50Z")

</div>

@Mattches - OP reports “the above post is closed but the issue is still there”

And, @leh [reports, above](https://community.brave.app/t/bug-not-resolved/647961/2) “can reproduce the fake tab strip on Brave beta 1.86.128” . . . and also reports “bug only happens if I use `Enable bottom navigation toolbar` in Settings \> Appearance”.

---

<div class="post-metadata">

**Author:** ![Mattches](https://sea1.discourse-cdn.com/brave/user_avatar/community.brave.app/mattches/32/25189_2.png) [@Mattches](https://community.brave.app/u/Mattches)\
**Post date:** [January 12, 2026, 6:09pm UTC](https://community.brave.app/t/bug-not-resolved/647961/4 "2026-01-12T18:09:31Z")

</div>

I can re-open the thread if you’d like. The Github issue is still open and active: [https://github.com/brave/brave-browser/issues/47959](https://github.com/brave/brave-browser/issues/47959)

---

<div class="post-metadata">

**Author:** ![thecs](https://avatars.discourse-cdn.com/v4/letter/t/a8b319/32.png) [@thecs](https://community.brave.app/u/thecs)\
**Post date:** [January 13, 2026, 9:55am UTC](https://community.brave.app/t/bug-not-resolved/647961/5 "2026-01-13T09:55:10Z")

</div>

As I mentioned in the last closed post, the issue I reported is not related to the Git issue you shared.

In the previous post, I was unable to provide an Incognito tab recording of the fake tab strip because I did not know the steps to reproduce the bug. However, thanks to @leh comment, I was able to reproduce the issue and record it in an Incognito tab as well.

I am now sharing the video with you. Kindly please check this, as this issue has been ongoing for more than 6–7 months.

@Mattches

---

<div class="post-metadata">

**Author:** ![Mattches](https://sea1.discourse-cdn.com/brave/user_avatar/community.brave.app/mattches/32/25189_2.png) [@Mattches](https://community.brave.app/u/Mattches)\
**Post date:** [January 13, 2026, 5:45pm UTC](https://community.brave.app/t/bug-not-resolved/647961/6 "2026-01-13T17:45:04Z")

</div>

I see, apologies on that. However I do believe we’ve captured this issue already – this one seems to match:

> <https://github.com/brave/brave-browser/issues/51883>
>
> \### Description
> 
> When you're within a tab group and open a new tab using the \`+\`… button via the \`tab switcher\`, you'll notice that the previous group toolbar is also appearing on the newly created tab even though it's not part of the group. Going back to the \`tab switcher\` and then back to the tab will remove the group toolbar. However, scrolling doesn't remove it.
> 
> \### Steps to reproduce
> 
> 1. on a new profile, visit https://www.motorsport.com/f1/news/
> 2. open several of the articles using \`Open in new tab group\`
> 3. once you have ~2-3 opened, tap on the \`tab switcher\`
> 4. tap on \`+\` to create a new tab and visit any website
> 5. notice that the \`group\` toolbar from the previous \`group\` is being displayed even though the tab isn't in the group
> 6. scroll through the website and you'll notice that the \`group toolbar\` is still visible
> 7. tap on the \`tab switcher\` and then go back into the same tab and you'll notice the toolbar finally disappears
> 
> \*\*\`Quick Note:\`\*\* Issue usually happens when you create a new tab via the \`tab switcher\` right after you've opened a tab within a group.
> 
> \### Actual result
> 
> Video of the issue occurring -\> https://youtube.com/shorts/tWUeg5Rf0-c (too large to upload into GH)
> 
> \*\*\`Example\*\* | \*\*\`Example\`\*\*
> \---------------|-----------------
> \<img width="1344" height="2992" alt="Image" src="https://github.com/user-attachments/assets/97f0d7b6-1c1c-47b3-a061-043480e3af96" /\> | \<img width="1344" height="2992" alt="Image" src="https://github.com/user-attachments/assets/387b715f-61ab-4ab6-b7d3-5e679d7aeb67" /\>
> 
> \### Expected result
> 
> The \`tab group\` toolbar shouldn't be shown in the above scenario as the tab doesn't belong to any groups.
> 
> \### Reproduces how often
> 
> Easily reproduced
> 
> \### Brave version
> 
> \`\`\`
> Brave | 1.85.120 Chromium: 143.0.7499.192 (Official Build) (64-bit)
> \--- | ---
> Revision | 33233fa7cb0c86387758b2588611deabfb6d69e8
> OS | Android 16; Build/BP4A.251205.006.E1; 36; REL
> \`\`\`
> 
> \`\`\`
> Brave | 1.86.135 Chromium: 144.0.7559.59 (Official Build) (64-bit)
> \--- | ---
> Revision | 1ff4e8bccafb01c14b7742ce3c28ed7b2208f08e
> OS | Android 16; Build/BP4A.251205.006.E1; 36; REL
> \`\`\`
> 
> \### Device
> 
> \- Brand/model: \`Pixel 8 Pro\`
> \- Android version: \`Android 16\`
> 
> \### Channel information
> 
> \- \[x\] release (stable)
> \- \[x\] beta
> \- \[x\] nightly
> 
> \### Reproducibility
> 
> \- \[\] with Brave Shields disabled
> \- \[\] with Brave Rewards disabled
> \- \[\] in the latest version of Chrome
> 
> \### Miscellaneous information
> 
> \_No response\_

[![](https://global.discourse-cdn.com/brave/original/3X/e/2/e29b5887e84fcd77c75ea9351e2b80f7b3d780db.jpeg "tab group toolbar being displayed when opening a new non-group tab from a tab group #51883") ](https://www.youtube.com/watch?v=tWUeg5Rf0-c)

---

<div class="post-metadata">

**Author:** ![Mfh1973](https://avatars.discourse-cdn.com/v4/letter/m/dbc845/32.png) [@Mfh1973](https://community.brave.app/u/Mfh1973)\
**Post date:** [January 20, 2026, 7:29pm UTC](https://community.brave.app/t/bug-not-resolved/647961/7 "2026-01-20T19:29:38Z")

</div>

Does brave just stop trying to fix some bugs after awhile? Like this one and the video dimming or going black one that’s been going on for a lot longer?

---

<div class="post-metadata">

**Author:** ![Mattches](https://sea1.discourse-cdn.com/brave/user_avatar/community.brave.app/mattches/32/25189_2.png) [@Mattches](https://community.brave.app/u/Mattches)\
**Post date:** [January 20, 2026, 8:11pm UTC](https://community.brave.app/t/bug-not-resolved/647961/8 "2026-01-20T20:11:10Z")

</div>

@Mfh1973 as you can see in the above issue, it’s been moved into the appropriate project board and is ready to be worked on.

The screen dimming issue occurs in other Chromium browsers as well so it likely needs an upstream fix. That said, there is a potential workaround in the meantime that has worked for some users you can try changing these flag values:

1. Disable `Tab Strip Group Drag Drop Android` flag.
2. Disable `Block screen fingerprinting` flag.
3. Enable `Enables use of the screen parameter for requestFullscreen` flag.

Make sure you relaunch after changing the flags and test to see if the issue is resolved for you. Issue is being tracked here:

> <https://github.com/brave/brave-browser/issues/44097>
>
> \### Description
> 
> Screen is dimming & locking for users while videos are playing …in Brave. 
> 
> What we know: 
> 
> \- Users that have replied say it is not reproducible in Chrome. 
> \- Not specific to any one site. 
> \- Disabling adaptive dimming does not resolve 
> 
> \### Steps to reproduce
> 
> 1. Play a video on Brave 
> 2. After a short time, screen dims and then locks 
> 
> 
> \### Actual result
> 
> Screen is locking for users reporting the issue. 
> 
> \### Expected result
> 
> Video continues to play as expected without dimming and locking. 
> 
> \### Reproduces how often
> 
> Intermittent issue
> 
> \### Brave version
> 
> Bug introduced with 1.75.175. Many users are reporting that it's happening regularly, with others affected only intermittently. 
> 
> \### Device
> 
> User 1: Android 14, Samsung S21FE, One UI ver: 6.1
> User 2: 1 Galaxy S23 - OS unknown 
> User 3 - Android 14, One UI 6.1.1, Kernal 5.10.209
> User 4: Android 12; Build/SKQ1.211019.001 on MIUI 14 Xiaomi Redmi Note 9s.
> User 5: Android 14, TECNO CK8n
> 
> \### Channel information
> 
> \- \[x\] release (stable)
> \- \[x\] beta
> \- \[\] nightly
> 
> \### Reproducibility
> 
> \- \[x\] with Brave Shields disabled
> \- \[x\] with Brave Rewards disabled
> \- \[x\] in the latest version of Chrome
> 
> \### Miscellaneous information
> 
> https://community.brave.com/t/screen-turning-off-while-watching-videos-on-brave-after-the-new-update-the-screen-turns-off-when-watching-a-video-on-brave-i-dont-want-to-change-my-phone-settings-i-want-this-issue-to-be-fixed-within-the-app/597751/66
> 
> Misc User Notes: 
> 
> \- Mixed results with Disabling Shields. Resolved for 1 user, not for another. 
> \- Clearing cache resolved for 1 user
> \- Changed the screen timeout in phone Settings\> Display and noticed-
> a) 5 mins = Screen turns off after 5 mins of video play.
> b) 15 seconds = Screen turns off after 15 seconds of video play.
> c) Screen only turns off when you don't touch the phone (display ofcourse).

---

<div class="post-metadata">

**Author:** ![thecs](https://avatars.discourse-cdn.com/v4/letter/t/a8b319/32.png) [@thecs](https://community.brave.app/u/thecs)\
**Post date:** [January 21, 2026, 5:16am UTC](https://community.brave.app/t/bug-not-resolved/647961/9 "2026-01-21T05:16:02Z")

</div>

@Mattches I’m really getting tired of hearing “it’s an upstream issue” every time something breaks.

You guys are a big browser company, and you’re milking Chromium hard — you don’t even contribute back. Microsoft devs go in and fix things upstream, but you just sit back, patch things in your fork, and call it a day. It’s not fair to the open-source community. You’re taking the whole cake and giving nothing back. If you’re gonna use Chromium, at least help make it better.

---

<div class="post-metadata">

**Author:** ![MasterLink](https://sea1.discourse-cdn.com/brave/user_avatar/community.brave.app/masterlink/32/204132_2.png) [@MasterLink](https://community.brave.app/u/MasterLink)\
**Post date:** [January 21, 2026, 5:43am UTC](https://community.brave.app/t/bug-not-resolved/647961/10 "2026-01-21T05:43:42Z")

</div>

> [@thecs](#):
>
> I’m really getting tired of hearing “it’s an upstream issue” every time something breaks.

I’m going to say this as politely as possible, but as someone who’s developed code in assembly since the days of the 8086 and 68000, let me be clear.

Upstream issues happen, and all forks get affected by it. Things take time.

> [@thecs](#):
>
> Microsoft devs go in and fix things upstream

 ![image](https://global.discourse-cdn.com/brave/original/3X/7/e/7e81f4f8e6e4daafdf9c9a7b5cb1f68f1baf3e8e.png)  
Microsoft also has a lot more employees.

Brave has not only less money, they have less developers. They also are fixing a variety of other issues, many of which _are_ upstream.

Guess what I do as a fellow Brave user who helps others, I have multiple browsers installed. Chromium (where all these browsers come from) for one, because many of the issues people have here, can be replicated there. Chromium is **the** upstream code.

I suggest you learn some patience here, because getting mad will only slow things down as they deal with people arguing with them, when they can be trying to push reports or fixes upstream. This arguing and banter about the upstream issue is counterintuitive.

> [@thecs](#):
>
> but you just sit back, patch things in your fork, and call it a day. . . . . . . .You’re taking the whole cake and giving nothing back.

They are an active contributor. Saying things without proof is slander, just an FYI.

> <https://github.com/chromium/chromium/blob/main/AUTHORS>

Line 1800:  
 ![image](https://global.discourse-cdn.com/brave/original/3X/d/b/dbfbd9e6b1eca89d2efb5c80e4b0834e8ee5f008.png)

That wasn’t added there just for lols. Again, be careful with slander.

Now for the meat and bones of the issue: Brave can’t just willy nilly fix things. Some browsers may already be working on their own “workaround” to certain Chromium bugs, so if that was just _fixed_ it breaks other forks then. Also Google is still primary contributor to Chromium, around 94% in 2024 alone. Of course every other company is going to look like peas as a contributor. Also, Brave’s contribution’s usually are privacy focused. It _is_ their specialty after all.

Hope this helps and clears up the world of software development. 😉

---

<div class="post-metadata">

**Author:** ![thecs](https://avatars.discourse-cdn.com/v4/letter/t/a8b319/32.png) [@thecs](https://community.brave.app/u/thecs)\
**Post date:** [January 22, 2026, 4:05am UTC](https://community.brave.app/t/bug-not-resolved/647961/11 "2026-01-22T04:05:48Z")

</div>

I don’t know, man — I’m facing a lot of bugs in Brave right now. Whenever I look them up, most of them are labeled as “upstream issues.” That might make sense from a development perspective, but as an end user, I honestly don’t care whether it’s Chromium or some other engine underneath.

These issues have been around for months, sometimes even longer, with no fix in sight. I’ve reported some of them directly to Brave, but they just get marked as upstream issues. As a Brave user, if I report a problem, I expect Brave to take ownership of it and fix it — or at least provide a clear workaround or timeline — not just pass it upstream and leave users waiting for months or even a year.

---

<div class="post-metadata">

**Author:** ![MasterLink](https://sea1.discourse-cdn.com/brave/user_avatar/community.brave.app/masterlink/32/204132_2.png) [@MasterLink](https://community.brave.app/u/MasterLink)\
**Post date:** [January 22, 2026, 4:45am UTC](https://community.brave.app/t/bug-not-resolved/647961/12 "2026-01-22T04:45:51Z")

</div>

> [@thecs](#):
>
> but as an end user, I honestly don’t care whether it’s Chromium or some other engine underneath.

I get it, I’m an end user too. But I also have been working with computers long enough to know how forks work. When you use a fork, this happens.

So again, you can’t force something just because as an end user you don’t like it. We don’t like it either, and I bet the devs don’t either. But again it does take time.

> [@thecs](#):
>
> These issues have been around for months, sometimes even longer, with no fix in sight.

I’m gonna link you to one of my own complaints and lead by example here: [Broken 30-bit color when ACM enabled with scRGB color space](https://community.brave.app/t/broken-30-bit-color-when-acm-enabled-with-scrgb-color-space/641950/)

See how the issue not only went unsolved and ignored? Check my edits and my own replies to myself, I ended up realizing it was a Chromium regression. So know what I did? Filed a ticket with Chromium. But guess what, it went nowhere there as well.

Do I expect Brave to fix it? Well, no. They specialize in privacy, security, that stuff. Half the devs probably don’t even have a setup like mine to have a 30-bit color depth to use the color space I use, so it falls in the cracks.

Point is, I found where the issue was, and don’t blame nor expect Brave to fix it, because I know Brave is a fork of Chromium.

> [@thecs](#):
>
> not just pass it upstream and leave users waiting for months or even a year.

Do realize, it’s Chromium’s developers that leave users waiting months to years. I know, I’ve dealt with them in the _past_.

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/brave/original/3X/1/8/182067f3480d1a5e7aea5ae3131b116ca1ef7918.png) [@system](https://community.brave.app/u/system)\
**Post date:** [February 21, 2026, 4:46am UTC](https://community.brave.app/t/bug-not-resolved/647961/13 "2026-02-21T04:46:27Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
