joonas-yoon
문제를 보면서 제출할 수 있는 기능
좀 더 구체적으로 말씀해주실 수 있나요?
제출 페이지에서 문제가 어떻게 보이는 것을 원하시는 지 모르겠어요.
문제 제목, 문제 설명만 보이면 되는건가요?
아하! 그럼 문제 보기 화면에서 제출창이 윈도우로 뜨는 게 더 나을 것 같은데 그건 어떠세요?
LeetCode나 Programmers 처럼요.
예전에 비슷하게 시도해본게 있어서, iframe 쓰면 될 거 같기는 한데 이쁠지는 모르겠네요.
한번 해보면서 경과를 여기에 적어볼게요 🤔
저도 만들려다가 실패.. 그래서 생각한 아이디어가 html 코드를 가져오는건데 https://github.com/byongshintv/backjoon-cpp-resolver/blob/main/src/request.js 이걸 참고하시면 좋을듯요
네 그런 방법도 있긴 한데, 코드 에디터쪽으로 실행되는 스크립트가 많을 거에요.
iframe으로 가져온 DOM도 컨트롤이 가능해서 그게 더 편할 것 같네요
@joonas-yoon ~~호스트가~~ Origin이 같아서 CORS가 발생하진 않을 겁니다. ( -> 상위 프레임에서 직접 iframe DOM 조작 가능하다는 의미 ) 다만 최근 업데이트처럼 요청 헤더 일부를 변경하셔야 empty body를 받는 경우를 제외할 수 있습니다.
rules.json 의 14번 라인에 ResourceType으로 "sub_frame" 을 추가해주시면 됩니다.
"resourceTypes": ["xmlhttprequest", "sub_frame"]
- 오전 05:55 2022-08-25 정정 호스트 -> Origin, 익명의 지인분이 "응~ 그거 아니야~" 라고 하셔서 정정합니다 😅 ;;
추가적으로 호스트가 다른 곳에서 가져오는 iframe 의 조작이 필요하시다면
별도의 스크립트를 추가 작성하셔서 match에 추가하시면서 "all_frames": true 로 모든 프레임에 대해서
적용하시는 것이 낫습니다. 적용된 타 익스텐션 샘플 : manifest.json
위에 말씀하신 것처럼 iframe 으로 넣은 다음에 iframe_1.contentDocument. ,,, 로 DOM 조작하는 것도 괜찮은 것 같습니다.
제 추천은 fetch로 페이지를 가져온 다음에 const doc = new DOMParser().((await response.text()), 'text/html');
로 파싱해서 가공해서 별도의 div태그나 프레임을 만들어서 새로 만드는 것이 좋은 것 같습니다. (의견)
다만,,, 이 방법으로 하면 이미지 경로가 relative인 것들은 absolute 경로로 다시 바꿔주는 추가 작업이 필요하긴 합니다. ;(
@smartwe 그래서 처음 제안하신 iframe 이 더 나을 것 같기도...? 합니다. 😅 가져온 iframe에 대해서 필요없는 HTMLElement의 삭제나 CSS 재적용 작업이 조금 하드할 것 같다는 느낌이네요.
아니면 또 제가 생각해본게 https://github.com/byongshintv/backjoon-cpp-resolver/blob/main/src/request.js 이분 소스코드를 참고하는 건데 흠.. 괜찮을까요?ㅎㅎ
@smartwe 위에 올린 링크의 소스코드 방식이 적절할 것으로 보이네요. 이번 기회에 pull request 한번 해보심이 어떠실까요. 😄
이미 충분히 많은 이야기가 오간 것 같네요 ㅎㅎ
저도 iframe으로 충분할거라고 생각은 합니다만, 개인적으로 선호하지 않고 사용하지도 않으려합니다. HTML5 표준이 아닌 것으로 알고 있고 브라우저에서도 언제 지원이 끊길지 모르는 일이라서요.
그런데 멀리 안가도 비슷한 동작을 하는 코드가 이미 BOJ Extended 내에 이미 있습니다 :)
https://github.com/joonas-yoon/boj-extended/blob/053cb428bcc255911a9936bbc1c1d69c979b1417/js/features/problem.js#L44,L65
여기는 간단하게 DOMParser() 로 필요한 부분만 읽으면 됐는데, 문제는 위에 언급했듯이 에디터 관련 스크립트들입니다.
그래서 처음 제안하신 iframe 이 더 나을 것 같기도...? 합니다. 😅 가져온 iframe에 대해서 필요없는 HTMLElement의 삭제나 CSS 재적용 작업이 조금 하드할 것 같다는 느낌이네요.
맞습니다. 이러한 이유로 iframe을 처음에 이야기를 꺼낸거였는데, 두 방법을 모두 고민해봐야할 것 같네요 ㅎㅎ..
안녕하세요, iframe으로 간단하게 테스트를 해봤는데, iframe 내의 DOM이 로드되면서 BOJ Extended가 스크립트를 실행을 시도하다 오류를 내버리네요. (정확히는 document.createElement 구문 실행을 실패하는데 이건 좀 더 알아보도록 하겠습니다)
참고로, manifest 설정에서 content_scripts 아래에 all_frames: true 이기 때문에 iframe에 대해서도 확장 프로그램은 동작하긴 합니다.
그리고 두 가지의 Mock-up이 있습니다.
Type A
좌우로 나누어 사이드바 형태로 표시하는 방식. 대신 기존의 문제 설명들의 레이아웃이 좁아짐.
Type B
기존의 메모 작성하기처럼, 문제 하단에 제출 버튼을 통해 표시. 대신 이 방법은 UX 1단계가 추가됨
저는 개인적으로 Type B가 나아보입니다. 제출 페이지는 "로그인 한 유저"에게만 보이는 페이지인데요, Type A는 UI 변화가 커서 로그인/비로그인 상태에 따라서 UI가 다른 점이 많이 우려되네요.
그리고 이 기능 전체가 CSRF 공격을 모방할 수 있겠다는 생각이 들더라구요.
넘어가는 데이터를 보면 csrf_token이 있는데, 제출 페이지를 직접 로드해서 가져왔을 때 이게 과연 그대로 유효하게 사용될 수 있을지는 모르겠습니다. (확인이 필요함)
그래서 우회하는 방법으로는, Type A/B 처럼 제출 폼(a)만 동일하게 보여주고 실제로 제출 버튼을 누르면 폼(a)에서 작성했던 내용을 그대로 적용시켜주는 형태가 되지 않을까합니다.
그래서 우회하는 방법으로는, Type A/B 처럼 제출 폼(a)만 동일하게 보여주고 실제로 제출 버튼을 누르면 폼(a)에서 작성했던 내용을 그대로 적용시켜주는 형태가 되지 않을까합니다.
위 내용을 구현해보려고 했는데요. 제출하기 페이지에 적용되는 코드 WYSIWYG 에디터(CodeMirror)와 완전히 동일하게 보이도록 적용하는게 어려워서 이 이슈는 보류하도록 하겠습니다.
CodeMirror를 이중으로 불러오는 것도 불필요해보이고, 에디터가 적용이 안 된다면 포맷팅이 전혀 안되어서 미리 작성하는 의미가 없어질 것 같아서요.
다음에 방법이 생각나고 구현하게 된다면 여기 이슈를 참고하도록 하겠습니다 :) 감사합니다.