luci-base: Make some tables better searchable

[Ramon00]

This changes the "name" in specific tables from being painted to being rendered. This allows the use of "ctrl-f" in browsers to e.g. search for firewall rule names.

Can anybody test this out? If no issues, I will then also change the other themes.

P.S. Any reason why there is 2nd section in the css file:

.cbi-section-table-titles.named::before,
.cbi-section-table-descr.named::before,
.cbi-section-table-row[data-title]::before {

Maybe just remove this as well?

[systemcrash]

Is there a quick litmus test that I can use to verify the changes? I use FF and search works fine there.

[vincejv]

@systemcrash the issue is reproducible on Chromium based browsers

Steps to reproduce

1. Go to Luci > Network Firewall > Traffic Rules
2. Press CTRL+F to bring up browser search functionality
3. Enter search term that can be found in the page
4. Does not return anything as reported by browser as seen in the screenshot

[systemcrash]

Thanks @vincejv - I'm aware. I don't run Chrome anything, which is why I ask for another way to verify...

[jow-]

Please test on a mobile screen after this change, that content approach was used to be able to dynamically hide/re-position row titles to headlines when decomposing the table into cards.

[Ramon00]

Thanks @vincejv - I'm aware. I don't run Chrome anything, which is why I ask for another way to verify...

I think the progession part is sufficiently tested. I think testing regression impact is more important, i.e. is the visual layout affected? So Firefox test would be great to do as well.

Please test on a mobile screen after this change, that content approach was used to be able to dynamically hide/re-position row titles to headlines when decomposing the table into cards.

If i view it portrait on mobile its pretty identical (other than a grey background bar missing in e.g. the rule name).

Oh also the text is not in bold anymore (mobile or desktop), its same style as the other text, if needed I can make it bold again, if people prefer that. (The bold was not that functional I thought, but im fine either way). Just let me know what people prefer.

[vincejv]

@systemcrash

I use FF and search works fine there.
which is why I ask for another way to verify...

it doesn't work on Safari either, tested on iPhone with iOS 26.2, now if someone can do the same test on Mac.

[Ramon00]

@systemcrash

I use FF and search works fine there.
which is why I ask for another way to verify...

it doesn't work on Safari either, tested on iPhone with iOS 26.2, now if someone can do the same test on Mac.

Chromium based browsers suffer from this "feature" (=not searching painted items). This is a design choice as those ::before elements should only contain visual things, not relevant information. We can question if this is the right choice in the browser or not, but regardless, chromium based browsers suffer from this. I think the market share is enough of chromium based browsers to warrant fixing this.

What I do think needs maybe more testing is if on all browsers the patch does not mess up the layout anywhere (we dont want to substitute one issue for another).

[vincejv]

safari is not chromium based though. However chromium based browsers uses blink engine which was forked from WebKit.

this design decision could stem back from WebKit. So if we fix this upstream, we have to file 2 separate issues for both WebKit/Safari and Chromium. However, since search only “works” correctly in Firefox, I agree with you that it makes sense to follow the behavior of the two engines with much larger user bases.

[Ramon00]

I agree
(the point i was trying to make, that i dont think it makes sense to do a full inventory of which browser has the issue and which browser does not, before fixing it)