Fixed link in wdb infobar is not clickable in some situation

[simonhong]

fix brave/brave-browser#28139

Resolves

Submitter Checklist:

• I confirm that no security/privacy review is needed, or that I have requested one
• There is a ticket for my issue
• Used Github auto-closing keywords in the PR description above
• Wrote a good PR/commit description
• Squashed any review feedback or "fixup" commits before merge, so that history is a record of what happened in the repo, not your PR
• Added appropriate labels (QA/Yes or QA/No; release-notes/include or release-notes/exclude; OS/...) to the associated issue
• Checked the PR locally:
  • npm run test -- brave_browser_tests, npm run test -- brave_unit_tests wiki
  • npm run lint, npm run presubmit wiki, npm run gn_check, npm run tslint
• Ran git rebase master (if needed)

Reviewer Checklist:

• A security review is not needed, or a link to one is included in the PR description
• New files have MPL-2.0 license header
• Adequate test coverage exists to prevent regressions
• Major classes, functions and non-trivial code blocks are well-commented
• Changes in component dependencies are properly reflected in gn
• Code follows the style guide
• Test plan is specified in PR before merging

After-merge Checklist:

• The associated issue milestone is set to the smallest version that the
  changes has landed on
• All relevant documentation has been updated, for instance:
  • https://github.com/brave/brave-browser/wiki/Deviations-from-Chromium-(features-we-disable-or-remove)
  • https://github.com/brave/brave-browser/wiki/Proxy-redirected-URLs
  • https://github.com/brave/brave-browser/wiki/Fingerprinting-Protections
  • https://github.com/brave/brave-browser/wiki/Brave%E2%80%99s-Use-of-Referral-Codes
  • https://github.com/brave/brave-browser/wiki/Custom-Headers
  • https://github.com/brave/brave-browser/wiki/Web-Compatibility-Exceptions-in-Brave
  • https://github.com/brave/brave-browser/wiki/QA-Guide
  • https://github.com/brave/brave-browser/wiki/P3A

Test Plan:

1. Launch brave with clean profile
2. Set Brave Search as a default search engine
3. Load https://search.brave.com/ and check wdp infobar is launched
4. Check clicking more info works regardless of window width size

[sangwoo108]

LGTM!

[sangwoo108]

Whoa, this must have been hard to find out! Well spotted!

Layout() seems to be called whenever mouse hovers and exits the LinkFragment. And it's caused by SetFontList() even it already has a font list with desired style(underlined), which seems to be a bug. Resetting font list triggers full cycle of layout from the top of browser view tree. So following code seems to make it not to relayout everyting.

void LinkFragment::RecalculateFont() {
  // Check whether any link fragment should be underlined.
  bool should_be_underlined = IsUnderlined();
  for (LinkFragment* current_fragment = next_fragment_;
       !should_be_underlined && current_fragment != this;
       current_fragment = current_fragment->next_fragment_) {
    should_be_underlined = current_fragment->IsUnderlied();
  }

  // If the style differs from the current one, update.
  if ((font_list().GetFontStyle() & gfx::Font::UNDERLINE) !=
      should_be_underlined) {
    auto MaybeUpdateStyle = [should_be_underlined](LinkFragment* fragment) {
      const int style = fragment->font_list().GetFontStyle();
      const int intended_style = should_be_underlined
                                     ? (style | gfx::Font::UNDERLINE)
                                     : (style & ~gfx::Font::UNDERLINE);
+      if (style == intended_style)
+        return;
      fragment->Label::SetFontList(
          fragment->font_list().DeriveWithStyle(intended_style));
      fragment->SchedulePaint();
    };

And a potential problem with the current code could be when we set a new font to a fragment, then it won't be laid out without explictly changing the size of the fragment. But now that this is not our case, I'm okay with the current fix. It's up to you! But could you update comments here?

[simonhong]

Thanks for digging more. I added more comments about it and let's wait fixing from upstream.
One thing I'm still curious thing is this doesn't happen when StyleLable is not multilined.
Needs to investigate more later :)

[sangwoo108]

doesn't happen when StyleLable is not multilined.

Yeah, there seems to be multiple LinkFragments, and it doesn't look working well :(

[simonhong]

Ah, I see. it's LinkFragment issue.

[simonhong]

Set CI/Skip as only comment is updated from previsou all green commit.