Show messages for users if the ROOT_URL is wrong, show JavaScript errors (#18971)
* ROOT_URL issues: some users did wrong to there app.ini config, then:
* The assets can not be loaded (AppSubUrl != "" and users try to access http://host:3000/)
*The ROOT_URL is wrong, then many URLs in Gitea are broken.
Now Gitea show enough information to users.
* JavaScript error issues, there are many users affected by JavaScript errors, some are caused by frontend bugs, some are caused by broken customized templates. If these JS errors can be found at first time, then maintainers do not need to ask about how bug occurs again and again.
* Some people like to modify the `head.tmpl`, so we separate the script part to `head_script.tmpl`, then it's much safer.
* use specialized CSS class "js-global-error", end users still have a chance to hide error messages by customized CSS styles.
2022-03-30 13:52:24 +08:00
|
|
|
// DO NOT IMPORT window.config HERE!
|
2024-02-28 23:20:53 +01:00
|
|
|
// to make sure the error handler always works, we should never import `window.config`, because
|
|
|
|
|
// some user's custom template breaks it.
|
Show messages for users if the ROOT_URL is wrong, show JavaScript errors (#18971)
* ROOT_URL issues: some users did wrong to there app.ini config, then:
* The assets can not be loaded (AppSubUrl != "" and users try to access http://host:3000/)
*The ROOT_URL is wrong, then many URLs in Gitea are broken.
Now Gitea show enough information to users.
* JavaScript error issues, there are many users affected by JavaScript errors, some are caused by frontend bugs, some are caused by broken customized templates. If these JS errors can be found at first time, then maintainers do not need to ask about how bug occurs again and again.
* Some people like to modify the `head.tmpl`, so we separate the script part to `head_script.tmpl`, then it's much safer.
* use specialized CSS class "js-global-error", end users still have a chance to hide error messages by customized CSS styles.
2022-03-30 13:52:24 +08:00
|
|
|
|
|
|
|
|
// This sets up the URL prefix used in webpack's chunk loading.
|
|
|
|
|
// This file must be imported before any lazy-loading is being attempted.
|
2023-08-31 04:46:44 +02:00
|
|
|
__webpack_public_path__ = `${window.config?.assetUrlPrefix ?? '/assets'}/`;
|
Show messages for users if the ROOT_URL is wrong, show JavaScript errors (#18971)
* ROOT_URL issues: some users did wrong to there app.ini config, then:
* The assets can not be loaded (AppSubUrl != "" and users try to access http://host:3000/)
*The ROOT_URL is wrong, then many URLs in Gitea are broken.
Now Gitea show enough information to users.
* JavaScript error issues, there are many users affected by JavaScript errors, some are caused by frontend bugs, some are caused by broken customized templates. If these JS errors can be found at first time, then maintainers do not need to ask about how bug occurs again and again.
* Some people like to modify the `head.tmpl`, so we separate the script part to `head_script.tmpl`, then it's much safer.
* use specialized CSS class "js-global-error", end users still have a chance to hide error messages by customized CSS styles.
2022-03-30 13:52:24 +08:00
|
|
|
|
2024-05-18 21:07:09 +00:00
|
|
|
// Ignore external and some known internal errors that we are unable to currently fix.
|
|
|
|
|
function shouldIgnoreError(err) {
|
|
|
|
|
const assetBaseUrl = String(new URL(__webpack_public_path__, window.location.origin));
|
|
|
|
|
|
|
|
|
|
if (!(err instanceof Error)) return false;
|
|
|
|
|
// If the error stack trace does not include the base URL of our script assets, it likely came
|
|
|
|
|
// from a browser extension or inline script. Ignore these errors.
|
|
|
|
|
if (!err.stack?.includes(assetBaseUrl)) return true;
|
|
|
|
|
// Ignore some known internal errors that we are unable to currently fix (eg via Monaco).
|
|
|
|
|
const ignorePatterns = [
|
|
|
|
|
'/assets/js/monaco.', // https://codeberg.org/forgejo/forgejo/issues/3638 , https://github.com/go-gitea/gitea/issues/30861 , https://github.com/microsoft/monaco-editor/issues/4496
|
|
|
|
|
];
|
|
|
|
|
for (const pattern of ignorePatterns) {
|
|
|
|
|
if (err.stack?.includes(pattern)) return true;
|
|
|
|
|
}
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2024-03-09 18:37:29 +01:00
|
|
|
const filteredErrors = new Set([
|
|
|
|
|
'getModifierState is not a function', // https://github.com/microsoft/monaco-editor/issues/4325
|
|
|
|
|
]);
|
|
|
|
|
|
Show messages for users if the ROOT_URL is wrong, show JavaScript errors (#18971)
* ROOT_URL issues: some users did wrong to there app.ini config, then:
* The assets can not be loaded (AppSubUrl != "" and users try to access http://host:3000/)
*The ROOT_URL is wrong, then many URLs in Gitea are broken.
Now Gitea show enough information to users.
* JavaScript error issues, there are many users affected by JavaScript errors, some are caused by frontend bugs, some are caused by broken customized templates. If these JS errors can be found at first time, then maintainers do not need to ask about how bug occurs again and again.
* Some people like to modify the `head.tmpl`, so we separate the script part to `head_script.tmpl`, then it's much safer.
* use specialized CSS class "js-global-error", end users still have a chance to hide error messages by customized CSS styles.
2022-03-30 13:52:24 +08:00
|
|
|
export function showGlobalErrorMessage(msg) {
|
|
|
|
|
const pageContent = document.querySelector('.page-content');
|
|
|
|
|
if (!pageContent) return;
|
2024-01-21 22:23:08 +08:00
|
|
|
|
2024-03-09 18:37:29 +01:00
|
|
|
for (const filteredError of filteredErrors) {
|
|
|
|
|
if (msg.includes(filteredError)) return;
|
|
|
|
|
}
|
|
|
|
|
|
2024-01-21 22:23:08 +08:00
|
|
|
// compact the message to a data attribute to avoid too many duplicated messages
|
|
|
|
|
const msgCompact = msg.replace(/\W/g, '').trim();
|
|
|
|
|
let msgDiv = pageContent.querySelector(`.js-global-error[data-global-error-msg-compact="${msgCompact}"]`);
|
|
|
|
|
if (!msgDiv) {
|
|
|
|
|
const el = document.createElement('div');
|
2024-03-21 11:16:11 +01:00
|
|
|
el.innerHTML = `<div class="ui container negative message center aligned js-global-error tw-mt-[15px] tw-whitespace-pre-line"></div>`;
|
2024-01-21 22:23:08 +08:00
|
|
|
msgDiv = el.childNodes[0];
|
|
|
|
|
}
|
|
|
|
|
// merge duplicated messages into "the message (count)" format
|
|
|
|
|
const msgCount = Number(msgDiv.getAttribute(`data-global-error-msg-count`)) + 1;
|
|
|
|
|
msgDiv.setAttribute(`data-global-error-msg-compact`, msgCompact);
|
|
|
|
|
msgDiv.setAttribute(`data-global-error-msg-count`, msgCount.toString());
|
|
|
|
|
msgDiv.textContent = msg + (msgCount > 1 ? ` (${msgCount})` : '');
|
|
|
|
|
pageContent.prepend(msgDiv);
|
Show messages for users if the ROOT_URL is wrong, show JavaScript errors (#18971)
* ROOT_URL issues: some users did wrong to there app.ini config, then:
* The assets can not be loaded (AppSubUrl != "" and users try to access http://host:3000/)
*The ROOT_URL is wrong, then many URLs in Gitea are broken.
Now Gitea show enough information to users.
* JavaScript error issues, there are many users affected by JavaScript errors, some are caused by frontend bugs, some are caused by broken customized templates. If these JS errors can be found at first time, then maintainers do not need to ask about how bug occurs again and again.
* Some people like to modify the `head.tmpl`, so we separate the script part to `head_script.tmpl`, then it's much safer.
* use specialized CSS class "js-global-error", end users still have a chance to hide error messages by customized CSS styles.
2022-03-30 13:52:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
2024-02-28 23:20:53 +01:00
|
|
|
* @param {ErrorEvent|PromiseRejectionEvent} event - Event
|
|
|
|
|
* @param {string} event.message - Only present on ErrorEvent
|
|
|
|
|
* @param {string} event.error - Only present on ErrorEvent
|
|
|
|
|
* @param {string} event.type - Only present on ErrorEvent
|
|
|
|
|
* @param {string} event.filename - Only present on ErrorEvent
|
|
|
|
|
* @param {number} event.lineno - Only present on ErrorEvent
|
|
|
|
|
* @param {number} event.colno - Only present on ErrorEvent
|
|
|
|
|
* @param {string} event.reason - Only present on PromiseRejectionEvent
|
|
|
|
|
* @param {number} event.promise - Only present on PromiseRejectionEvent
|
Show messages for users if the ROOT_URL is wrong, show JavaScript errors (#18971)
* ROOT_URL issues: some users did wrong to there app.ini config, then:
* The assets can not be loaded (AppSubUrl != "" and users try to access http://host:3000/)
*The ROOT_URL is wrong, then many URLs in Gitea are broken.
Now Gitea show enough information to users.
* JavaScript error issues, there are many users affected by JavaScript errors, some are caused by frontend bugs, some are caused by broken customized templates. If these JS errors can be found at first time, then maintainers do not need to ask about how bug occurs again and again.
* Some people like to modify the `head.tmpl`, so we separate the script part to `head_script.tmpl`, then it's much safer.
* use specialized CSS class "js-global-error", end users still have a chance to hide error messages by customized CSS styles.
2022-03-30 13:52:24 +08:00
|
|
|
*/
|
2024-02-28 23:20:53 +01:00
|
|
|
function processWindowErrorEvent({error, reason, message, type, filename, lineno, colno}) {
|
|
|
|
|
const err = error ?? reason;
|
|
|
|
|
const {runModeIsProd} = window.config ?? {};
|
2024-02-22 22:21:43 +01:00
|
|
|
|
2024-05-09 13:49:37 +00:00
|
|
|
// `error` and `reason` are not guaranteed to be errors. If the value is falsy, it is likely a
|
2024-02-28 23:20:53 +01:00
|
|
|
// non-critical event from the browser. We log them but don't show them to users. Examples:
|
|
|
|
|
// - https://developer.mozilla.org/en-US/docs/Web/API/ResizeObserver#observation_errors
|
|
|
|
|
// - https://github.com/mozilla-mobile/firefox-ios/issues/10817
|
|
|
|
|
// - https://github.com/go-gitea/gitea/issues/20240
|
|
|
|
|
if (!err) {
|
|
|
|
|
if (message) console.error(new Error(message));
|
|
|
|
|
if (runModeIsProd) return;
|
2023-08-22 11:30:02 +09:00
|
|
|
}
|
2024-02-22 22:21:43 +01:00
|
|
|
|
2024-05-18 21:07:09 +00:00
|
|
|
// In production do not display errors that should be ignored.
|
|
|
|
|
if (runModeIsProd && shouldIgnoreError(err)) return;
|
2022-10-16 00:04:00 +02:00
|
|
|
|
2024-02-28 23:20:53 +01:00
|
|
|
let msg = err?.message ?? message;
|
|
|
|
|
if (lineno) msg += ` (${filename} @ ${lineno}:${colno})`;
|
|
|
|
|
const dot = msg.endsWith('.') ? '' : '.';
|
|
|
|
|
const renderedType = type === 'unhandledrejection' ? 'promise rejection' : type;
|
|
|
|
|
showGlobalErrorMessage(`JavaScript ${renderedType}: ${msg}${dot} Open browser console to see more details.`);
|
Show messages for users if the ROOT_URL is wrong, show JavaScript errors (#18971)
* ROOT_URL issues: some users did wrong to there app.ini config, then:
* The assets can not be loaded (AppSubUrl != "" and users try to access http://host:3000/)
*The ROOT_URL is wrong, then many URLs in Gitea are broken.
Now Gitea show enough information to users.
* JavaScript error issues, there are many users affected by JavaScript errors, some are caused by frontend bugs, some are caused by broken customized templates. If these JS errors can be found at first time, then maintainers do not need to ask about how bug occurs again and again.
* Some people like to modify the `head.tmpl`, so we separate the script part to `head_script.tmpl`, then it's much safer.
* use specialized CSS class "js-global-error", end users still have a chance to hide error messages by customized CSS styles.
2022-03-30 13:52:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
function initGlobalErrorHandler() {
|
2023-08-22 11:30:02 +09:00
|
|
|
if (window._globalHandlerErrors?._inited) {
|
|
|
|
|
showGlobalErrorMessage(`The global error handler has been initialized, do not initialize it again`);
|
|
|
|
|
return;
|
|
|
|
|
}
|
Show messages for users if the ROOT_URL is wrong, show JavaScript errors (#18971)
* ROOT_URL issues: some users did wrong to there app.ini config, then:
* The assets can not be loaded (AppSubUrl != "" and users try to access http://host:3000/)
*The ROOT_URL is wrong, then many URLs in Gitea are broken.
Now Gitea show enough information to users.
* JavaScript error issues, there are many users affected by JavaScript errors, some are caused by frontend bugs, some are caused by broken customized templates. If these JS errors can be found at first time, then maintainers do not need to ask about how bug occurs again and again.
* Some people like to modify the `head.tmpl`, so we separate the script part to `head_script.tmpl`, then it's much safer.
* use specialized CSS class "js-global-error", end users still have a chance to hide error messages by customized CSS styles.
2022-03-30 13:52:24 +08:00
|
|
|
if (!window.config) {
|
feat: Rebranding adicional de Gitea para DATAWARE Forge e ajustes em containers, Makefile, e integração
---------------------------------------------------------------
[PT-BR]
Este commit implementa a transição do rebranding de Forgejo/Gitea para DATAWARE Forge, realizando as seguintes alterações:
- Atualização dos arquivos de configuração de ambiente e containers:
- `.devcontainer/devcontainer.json` e `.gitpod.yml` agora exibem "DATAWARE Forge" em vez de "Gitea" ou "Forgejo".
- Ajustes no Makefile:
- Alteração do branding do Swagger para "DATAWARE Forge API" e modificação da mensagem de licença.
- Modificações em comandos e scripts:
- Em `cmd/generate.go`, a descrição foi atualizada para refletir "DATAWARE Forge's secrets/keys/tokens".
- Em `contrib/environment-to-ini/environment-to-ini.go`, foram adicionadas novas variantes de prefixos de variáveis de ambiente para suportar diversas formas (DATAWARE, DW, etc.).
- Inclusão de novos arquivos de serviço e init scripts:
- Novos scripts de init para Debian e Ubuntu foram adicionados, com descrições e comandos atualizados para DATAWARE Forge.
- Alterações em diversas partes do código (modelos, rotas, serviços, testes e webhooks):
- Todas as referências, mensagens, headers (ex.: X-DatawareForge-OTP, X-DatawareForge-Object-Type), endpoints, logs e textos foram atualizadas para substituir “Gitea” ou “Forgejo” por “DATAWARE Forge”.
- Ajustes em mensagens de erro e instruções de configuração (app.ini, README, etc.) para refletir a nova identidade.
- Atualizações em arquivos de configuração e templates (ex.: `custom/conf/app.example.ini`) para alinhar com a nova marca DATAWARE Forge.
Essas alterações consolidam a personalização white-label, garantindo a integridade do código original enquanto preparam o sistema para uso interno e futura distribuição a clientes.
---------------------------------------------------------------
[EN]
This commit implements a rebranding from Forgejo/Gitea to DATAWARE Forge, making the following changes:
- Updated environment and container configuration files:
- `.devcontainer/devcontainer.json` and `.gitpod.yml` now display "DATAWARE Forge" instead of "Gitea" or "Forgejo".
- Makefile adjustments:
- Changed the Swagger branding to "DATAWARE Forge API" and updated the license message.
- Modifications in commands and scripts:
- In `cmd/generate.go`, the usage description now reflects "DATAWARE Forge's secrets/keys/tokens".
- In `contrib/environment-to-ini/environment-to-ini.go`, new environment variable prefix variants have been added (DATAWARE, DW, etc.).
- Inclusion of new service and init scripts:
- New init scripts for Debian and Ubuntu have been added, with updated descriptions and commands for DATAWARE Forge.
- Changes across various parts of the code (models, routers, services, tests, and webhooks):
- All references, messages, headers (e.g., X-DatawareForge-OTP, X-DatawareForge-Object-Type), endpoints, logs, and texts have been updated to replace “Gitea”/“Forgejo” with “DATAWARE Forge”.
- Adjustments in error messages and configuration instructions (app.ini, README, etc.) to align with the new identity.
- Updates in configuration files and templates (e.g., `custom/conf/app.example.ini`) to match the new DATAWARE Forge branding.
These changes consolidate the white-label customization, ensuring the original code’s integrity while preparing the system for internal use and future client distribution.
Marcos A. Lucas <mlucas@dataware.com.br>
2025-03-09 06:22:45 -03:00
|
|
|
showGlobalErrorMessage(`DATAWARE Forge JavaScript code couldn't run correctly, please check your custom templates`);
|
Show messages for users if the ROOT_URL is wrong, show JavaScript errors (#18971)
* ROOT_URL issues: some users did wrong to there app.ini config, then:
* The assets can not be loaded (AppSubUrl != "" and users try to access http://host:3000/)
*The ROOT_URL is wrong, then many URLs in Gitea are broken.
Now Gitea show enough information to users.
* JavaScript error issues, there are many users affected by JavaScript errors, some are caused by frontend bugs, some are caused by broken customized templates. If these JS errors can be found at first time, then maintainers do not need to ask about how bug occurs again and again.
* Some people like to modify the `head.tmpl`, so we separate the script part to `head_script.tmpl`, then it's much safer.
* use specialized CSS class "js-global-error", end users still have a chance to hide error messages by customized CSS styles.
2022-03-30 13:52:24 +08:00
|
|
|
}
|
2024-02-28 23:20:53 +01:00
|
|
|
// we added an event handler for window error at the very beginning of <script> of page head the
|
|
|
|
|
// handler calls `_globalHandlerErrors.push` (array method) to record all errors occur before
|
|
|
|
|
// this init then in this init, we can collect all error events and show them.
|
Show messages for users if the ROOT_URL is wrong, show JavaScript errors (#18971)
* ROOT_URL issues: some users did wrong to there app.ini config, then:
* The assets can not be loaded (AppSubUrl != "" and users try to access http://host:3000/)
*The ROOT_URL is wrong, then many URLs in Gitea are broken.
Now Gitea show enough information to users.
* JavaScript error issues, there are many users affected by JavaScript errors, some are caused by frontend bugs, some are caused by broken customized templates. If these JS errors can be found at first time, then maintainers do not need to ask about how bug occurs again and again.
* Some people like to modify the `head.tmpl`, so we separate the script part to `head_script.tmpl`, then it's much safer.
* use specialized CSS class "js-global-error", end users still have a chance to hide error messages by customized CSS styles.
2022-03-30 13:52:24 +08:00
|
|
|
for (const e of window._globalHandlerErrors || []) {
|
|
|
|
|
processWindowErrorEvent(e);
|
|
|
|
|
}
|
2024-02-28 23:20:53 +01:00
|
|
|
// then, change _globalHandlerErrors to an object with push method, to process further error
|
|
|
|
|
// events directly
|
2023-08-22 11:30:02 +09:00
|
|
|
window._globalHandlerErrors = {_inited: true, push: (e) => processWindowErrorEvent(e)};
|
Show messages for users if the ROOT_URL is wrong, show JavaScript errors (#18971)
* ROOT_URL issues: some users did wrong to there app.ini config, then:
* The assets can not be loaded (AppSubUrl != "" and users try to access http://host:3000/)
*The ROOT_URL is wrong, then many URLs in Gitea are broken.
Now Gitea show enough information to users.
* JavaScript error issues, there are many users affected by JavaScript errors, some are caused by frontend bugs, some are caused by broken customized templates. If these JS errors can be found at first time, then maintainers do not need to ask about how bug occurs again and again.
* Some people like to modify the `head.tmpl`, so we separate the script part to `head_script.tmpl`, then it's much safer.
* use specialized CSS class "js-global-error", end users still have a chance to hide error messages by customized CSS styles.
2022-03-30 13:52:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
initGlobalErrorHandler();
|