Closed Bug 1944927 Opened 20 days ago Closed 9 days ago

userContent.css instructions for "new tab" gets ignored on first load.

Categories

(Core :: CSS Parsing and Computation, defect)

defect

Tracking

()

RESOLVED INVALID

People

(Reporter: pomax, Unassigned)

Details

Attachments

(2 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:136.0) Gecko/20100101 Firefox/136.0

Steps to reproduce:

[FF Nightly, Windows 10 Pro x64]

  • create a ./chrome/userContent.css file with @-moz-document url("about:newtab") { background: pink; } or something equally obvious in it.
  • make sure Firefox is set to show "new tab" on start
  • close Firefox
  • open Firefox

You are likely to see the userContent changes.

  • close Firefox again
  • open Firefox again

Actual results:

  • odds are good that the second time you open Firefox (especially relevant to Nightly, which wants to be restarted at least once a day) the userContent CSS does not kick in.
  • However, explicitly opening a new tab will cause it to kick in, resulting in Firefox having two tabs for the same page with different styling.

Expected results:

The CSS from userContent.css should have been loaded every time.

Attached image Start-up new tab view
Attached image explicit new tabe view

As example, the new tab shortcut spacing looks horribly off as of a few days ago, so I added a userContent.css bit that looks like:

@-moz-document url("about:newtab") {
  .activity-stream {
    .top-site-outer {
      margin: 0 !important;
      padding: 0 !important;
      height: 6em !important;
    }
  }
}

When I start Nightly, it completely ignores this CSS and looks like the:

https://bugzilla.mozilla.org/attachment.cgi?id=9463187

but if I then explicitly click "new tab", that new tab does have the userContent.css rules applied, and looks like:

https://bug1944927.bmoattachments.org/attachment.cgi?id=9463188

Component: Untriaged → New Tab Page

Hey Pomax, I think you need a rule for about:home too, and not just about:newtab.

Also fyi, we're doing another round of work on shortcuts. Try this pref: browser.newtabpage.activity-stream.newtabShortcuts.refresh

It might help out so you don't need the userContent change.

Looks like that worked, but only if I use "@-moz-document url-prefix(about:home), url-prefix(about:newtab)" and no other supposedly valid CSS. For example, I initially tried the more "CSS obvious" nested rule:

@-moz-document {
  url-prefix(about:home), url-prefix(about:newtab) {
    ...
  }
}

But neither that, nor the more traditional double-declaration worked:

@-moz-document url-prefix(about:home) {
  ...
}

@-moz-document url-prefix(about:newtab) {
  ...
}

So something super weird is going on with the parsing for this file...? (although technically no longer related to this specific bug)

Turning on the refresh toggle does indeed switch things over to the upcoming restyle, although that has its own quirks that still need a userContent.css file to get around (right now, mouse-over will recolor the background in such a way that it catches the upper half of the text label, and I can't say I agree with the calling reordered shortcuts "pinned", as I didn't put a specific icon in "spot 21" or the like, as far as I'm concerned as user, I instead "ordered" my shortcuts so that X is to the left or right of Y, so that pin icon is rather unwanted and userContent.css will have to fix the background and pin instead of the current spacing issue =)

Also tried this, which again just broke the whole CSS file:

@-moz-document url-prefix(about:home), 
@-moz-document url-prefix(about:newtab) {
  ...
}

This looks like this might just be how @-moz-document works? Looking around, all examples I saw would list them under the same @-moz-document rule, only using multiple @-moz-document when they had different functions, like url-prefix and domain. It also looks like this is fairly deprecated.

I'm not familiar with userContent, but can you not just select .activityStream?

Either way moving this back into Untriaged at the very least, as this doesn't seem specifically newtab related.

Component: New Tab Page → Untriaged

Trying to move to CSS parsing. Worth noting that there is a possibility that this will be close as INVALID, since user*.css are unsupported.

Component: Untriaged → CSS Parsing and Computation
Product: Firefox → Core
Status: UNCONFIRMED → RESOLVED
Closed: 9 days ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: