Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions play/index.html
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,9 @@
<!-- App Design -->
<meta name="msapplication-TileColor" content="{{ themeColor }}" />

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Inconsistent theme-color handling: hardcoded vs template variable.

Line 23 uses the template variable {{ themeColor }} for msapplication-TileColor, but line 25 hardcodes #000000 for theme-color. Both serve similar purposes (Windows tile color vs browser theme color) and should be consistent. All other dynamic meta tags (title, description, url, cardImage, etc.) still use template variables.

If theme-color must be hardcoded to #000000 for Universe branding, then msapplication-TileColor should also be hardcoded to match. Alternatively, both should use {{ themeColor }} to allow per-deployment customization.

🔧 Proposed fixes

Option A: Hardcode both for consistency (if Universe branding requires fixed black theme)

-        <meta name="msapplication-TileColor" content="{{ themeColor }}" />
+        <meta name="msapplication-TileColor" content="`#000000`" />
         <meta name="theme-color" content="`#000000`" />

Option B: Use template variable for both (if per-deployment customization is needed)

         <meta name="msapplication-TileColor" content="{{ themeColor }}" />
-        <meta name="theme-color" content="`#000000`" />
+        <meta name="theme-color" content="{{ themeColor }}" />

Also applies to: 25-25

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@play/index.html` at line 23, The two meta tags are inconsistent: <meta
name="msapplication-TileColor" content="{{ themeColor }}" /> and <meta
name="theme-color" content="`#000000`" />; pick one approach and make them match.
Either hardcode both values to "`#000000`" (change msapplication-TileColor to
"`#000000`") or make both use the template variable (change theme-color to "{{
themeColor }}"); update the tags accordingly so msapplication-TileColor and
theme-color are consistent.

<meta name="msapplication-TileImage" content="{{ msApplicationTileImage }}" />
<meta name="theme-color" content="{{ themeColor }}" />
<meta name="theme-color" content="#000000" />
<meta name="apple-mobile-web-app-capable" content="yes" />
<meta name="apple-mobile-web-app-title" content="Universe" />

<!-- Open Graph / Facebook -->
<meta property="og:type" content="website">
Expand All @@ -44,7 +46,7 @@
{{#favIcons}}
<link rel="{{ rel }}" type="image/png" sizes="{{ sizes }}" href="{{ src }}" />
{{/favIcons}}
<link rel="manifest" href="/static/images/favicons/manifest.json?url={{ url }}" />
<link rel="manifest" href="/manifest.webmanifest" />

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Check for references to the old manifest endpoint that may need updating

echo "=== Checking for hardcoded references to old manifest endpoint ==="
rg -n 'static/images/favicons/manifest.json' --type html --type ts --type js

echo -e "\n=== Checking if FrontController manifest handler can be safely removed ==="
rg -n 'displayManifestJson|static/images/favicons/manifest.json' play/src/pusher/controllers/FrontController.ts

echo -e "\n=== Verifying new manifest is being served correctly ==="
rg -n 'manifest.webmanifest' play/

Repository: BAWES-Universe/workadventure-universe

Length of output: 767


Breaking change: play/index.html now loads a static manifest, bypassing dynamic per-deployment metadata

  • play/index.html (line 49) now links to /manifest.webmanifest, so browsers will load the static file instead of the dynamically generated manifest.
  • The old dynamic endpoint /static/images/favicons/manifest.json is still implemented in play/src/pusher/controllers/FrontController.ts and calls displayManifestJson(..., query.url), but it’s no longer used via the default manifest link.
  • Deployments that previously depended on admin/map-based manifest customization will lose that behavior in the normal browser flow; either migrate/replace the dynamic behavior for the manifest link or provide a backward-compatible path for existing deployments.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@play/index.html` at line 49, The index now points to a static
/manifest.webmanifest which breaks per-deployment dynamic manifests; either
revert play/index.html to reference the dynamic endpoint
(/static/images/favicons/manifest.json) or make the dynamic generator serve at
/manifest.webmanifest instead; locate play/index.html and change the <link
rel="manifest"> href accordingly, or update FrontController.ts so the existing
displayManifestJson(...) handler (the function displayManifestJson and its route
in FrontController) is mounted at /manifest.webmanifest and returns the same
dynamic content and headers as the old path to restore backward compatibility.


<style>
/*hide cowebsite container before scss is loaded*/
Expand Down
24 changes: 24 additions & 0 deletions play/public/manifest.webmanifest
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
{
"name": "BAWES Universe",
"short_name": "Universe",
"description": "BAWES Universe - a virtual world",
"start_url": "/",
"scope": "/",
"display": "fullscreen",
"orientation": "landscape",
"background_color": "#000000",
"theme_color": "#000000",
"icons": [
{
"src": "/static/universe-icon-192.png",
"sizes": "192x192",
"type": "image/png"
},
{
"src": "/static/universe-icon-512.png",
"sizes": "512x512",
"type": "image/png",
"purpose": "maskable any"
}
Comment on lines +17 to +22

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: The PWA icon combines maskable and any purposes, causing it to appear shrunken in non-maskable contexts like home screen shortcuts.
Severity: LOW

Suggested Fix

Separate the icon definitions in manifest.webmanifest. Provide one icon entry with "purpose": "maskable" and another identical icon entry with "purpose": "any". This ensures the appropriate icon is used in each context, displaying correctly on home screens and in other UI surfaces.

Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: play/public/manifest.webmanifest#L17-L22

Potential issue: The 512px PWA icon in `manifest.webmanifest` specifies `"purpose":
"maskable any"`. This is an anti-pattern because browsers will use this single, padded
icon for both maskable and non-maskable (`any`) contexts. As a result, when a user adds
the PWA to their home screen, the icon will appear shrunken due to the unnecessary
safe-zone padding intended for masking, leading to inconsistent and poor branding
presentation.

Did we get this right? 👍 / 👎 to inform future reviews.

]
}
Binary file added play/public/static/universe-icon-192.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added play/public/static/universe-icon-512.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.